Atitit.軟件開發提高穩定性總結

Atitit.軟件開發提高穩定性總結

 

#----影響穩定性幾個類別 3

1. 資源和內存泄漏溢出 3

2. 數據庫/文件死鎖 3

3. 類庫衝突 3

4. 熱更新熱部署(業務可用性 3

5. 程序崩潰 3

6. 磁盤空間/cpu/內存佔用太高 3

#-----影響穩定性的因素 3

7. 內存泄漏溢出 3

8. 數據庫鏈接泄漏 3

9. 數據庫死鎖 3

10. 類庫衝突,形成部署問題 4

11. 熱更新的支持不足,部署比較麻煩 4

12. Web服務跟數據庫服務崩潰 4

13. 非託管資源的釋放 4

14. 其它的潛在隱患: 4

15. 多線程併發讀寫死鎖 4

16. 子線程異常形成主線程崩潰(java不影響,.net有這個問題) 4

17. 文件併發讀寫 5

18. 別的網絡socket鏈接釋放問題... 5

19. 直接內存讀寫 5

20. Stream的關閉釋放. 5

21. native method調用的內存 5

22. 磁盤空間不足,形成不少的莫名其妙的問題.或許提示鏈接耗盡.. 5

#----解決方法歸類總結 6

23. 更簡化的開發架構(熱更新熱部署).. 6

24. 更好用的第三方框架類庫 6

25. 類庫衝突避免(ide,檢測工具,開發時,執行時) 6

26. 引擎+腳本結構(c++,java+python,lua,php等) 6

27. 最佳推薦流程(避免死鎖跟解除) 6

28. 更簡化的編程語言 6

29. 提高穩定性的內部封裝框架/類庫 6

30. 本身主動資源釋放池 6

31. 監測,warnning,跟本身主動恢復 6

32. 壓力測試 6

33. 容錯(包含本身主動重連) 6

34. 語言級的新的特性 6

35. 故障集羣 6

#----解決方法總結 6

36. php/.net 6

37. 創建基於提高穩定性的內部封裝框架/流程文檔 7

38. Finalize/Dispose 7

39. 容錯(包含本身主動重連) 7

40. SoftReference 7

41. 鏈接池的配置: 本身主動超時回收Connection+超時本身主動斷開conn 7

42. 超時回收資源gc 8

43. 語句塊回收資源/using塊中本身主動調用Dispose 8

44. 崩潰時候兒core  dump並且從新啓動 8

45. 日誌。緩存等文件。儘量按時間生成多個文件。

。 8

46. 重要業務服務和頁面gui監測 8

47. 監測程序(cpu,內存佔用, io隊列深度, 磁盤空間,數據庫鏈接數,數據庫死鎖監測) 8

48. 網絡，文件操做使用wrap類庫secury方式調用 8

49. 死鎖自解除(數據庫,文件等) 9

#----壓力測試 9

 

做者 老哇的爪子 Attilax 艾龍，  EMAIL:1466519819@qq.com

轉載請註明來源： http://blog.csdn.net/attilax

 

#----影響穩定性幾個類別

1. 資源和內存泄漏溢出

2. 數據庫/文件死鎖

3. 類庫衝突

4. 熱更新熱部署(業務可用性

5. 程序崩潰

6. 磁盤空間/cpu/內存佔用太高

#-----影響穩定性的因素

 

7. 內存泄漏溢出

有時gc不起生效..可以調用native方法釋放內存. 

 new memory().start();監測內存佔用，當物理內存佔用超過此值M時。調用SetProcessWorkingSetSize方法回收內存。

8. 數據庫鏈接泄漏

鏈接池本身主動關閉鏈接,簡化開發,,同一時候提高性能..

9. 數據庫死鎖

避免多個線程/請求/事務改動同一個記錄..

不使用事務或者使用單語句事務

要是必須使用事務,需要調整代碼.

Dbms 可以探測到死鎖,但是不能本身主動釋放死鎖,需要監測程序本身主動解鎖鎖死的鏈接..(要是數據庫被多個應用使用,要改動驅動/或者使用反射嘗試,記錄此應用打開的鏈接port,到數據庫端過濾,在運行解鎖)

10. 類庫衝突,形成部署問題

需要工具檢測

11. 熱更新的支持不足,部署比較麻煩

Classloader??

 Resin  glassfish等webserver檢測...jboss支持有限的熱部署.

 

12. Web服務跟數據庫服務崩潰

數據庫服務啓用服務監測,本身主動恢復..Web服務單個的進程,需要尋找個監測程序或者安裝爲服務.

13. 非託管資源的釋放

託管資源交給GC就好，非託管資源則必須使用框架來本身主動回收 或者  親自寫代碼回收

14. 其它的潛在隱患:

15. 多線程併發讀寫死鎖

壓力測試解決.

16. 子線程異常形成主線程崩潰(java不影響,.net有這個問題)

拋出線程，線程體內要TRY CATCH。。不然拋出EXP導至主程序OUT。

。特別重要。必定要作.

17. 文件併發讀寫

18. 別的網絡socket鏈接釋放問題...

19. 直接內存讀寫

20. Stream的關閉釋放.

21.  native method調用的內存

finalize()中可以用本地方法來調用它。

以釋放這些「特殊」的內存空間。

 

22. 磁盤空間不足,形成不少的莫名其妙的問題.或許提示鏈接耗盡..

解決:加入監測程序 

 

#----解決方法歸類總結

23. 更簡化的開發架構(熱更新熱部署)..

24. 更好用的第三方框架類庫

25. 類庫衝突避免(ide,檢測工具,開發時,執行時)

26. 引擎+腳本結構(c++,java+python,lua,php等)

27. 最佳推薦流程(避免死鎖跟解除)

28. 更簡化的編程語言

29. 提高穩定性的內部封裝框架/類庫

30. 本身主動資源釋放池

31. 監測,warnning,跟本身主動恢復

32. 壓力測試

33. 容錯(包含本身主動重連)

34. 語言級的新的特性

35. 故障集羣

 

#----解決方法總結

36. php/.net 

Php的本身主動釋放資源作的很是好,差點兒所有的的問題都攻克了...同級的腳本語言ruby差點兒和php同一時候起步,python更是早好幾年,,終於市場php應用最普遍(c系列的語言風格也很是重要,跟c++,java 一脈相承)...ruby/python攻克了熱更新跟類庫衝突,但是好像都沒解決本身主動釋放資源的問題.

Java 也可以使用Quercus類庫內嵌python/Php/js,內嵌方式能不能本身主動釋放資源尚未檢驗

.net也攻克了部分穩定性問題.(主要是熱更新跟類庫衝突,但是沒解決資源本身主動釋放的問題) ,只是ide vs的強大大大提高了2倍以上的開發效率.

 

37. 創建基於提高穩定性的內部封裝框架/流程文檔

 

全面取代系統默認庫和常使用第三方庫,從框架級角度解決一些問題,,會損失一點兒性能跟靈活性..需要的時候兒也能直接使用系統庫...

創建api文檔已便查看..

38. Finalize/Dispose

finalize()的主要用途是釋放一些其它作法(non--new法)開闢的內存空間，以及作一些清理工做

使用code template配合ide本身主動生成Finalize框架方法

39. 容錯(包含本身主動重連)

 

40. SoftReference

java .lang.ref 包，當中定義了三種引用類。這三種引用類分別爲SoftReference、 WeakReference和

 

 

41. 鏈接池的配置: 本身主動超時回收Connection+超時本身主動斷開conn 

c3p0.checkoutTimeout=10000

c3p0.unreturnedConnectionTimeout=25

c3p0.maxConnectionAge=20 

 

 

42. 超時回收資源gc

需要創建框架,比較簡單的超時本身主動回收資源.可以解決大部分問題...使用code template配合ide本身主動import 本身定義類庫取代系統類庫.

 

43. 語句塊回收資源/using塊中本身主動調用Dispose

44. 崩潰時候兒core  dump並且從新啓動

Java的調用oom本身主動恢復腳本..

PRPGRAM。CS內要TRY CATCH，發現主程序出問題，從新啓動。

PROGRAME。CS內添加UnhandledException 的捕獲..

 

 

45. 日誌，緩存等文件。儘量按時間生成多個文件。

。

可以防止萬一個哪一個文件句柄沒被釋放，也不會影響後面的文件寫入。

 

46. 重要業務服務和頁面gui監測

可以及時發現服務out service

 

47. 監測程序(cpu,內存佔用, io隊列深度, 磁盤空間,數據庫鏈接數,數據庫死鎖監測)

提早發現不穩定性因素...

48. 網絡，文件操做使用wrap類庫secury方式調用

默認的sdk庫使用必定要TRYCATCH。

 

49. 死鎖自解除(數據庫,文件等)

 

#----壓力測試

當前項目儘管併發不大(當前200左右,默認的配置可支持5000左右)...

但是壓力測試可以提早測試出穩定性方面的問題..

 

經常使用工具jmeter,LoadRunner等