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 能夠探測到死鎖,可是不能自動釋放死鎖,須要監測程序自動解鎖鎖死的鏈接..(要是數據庫被多個應用使用,要修改驅動/或者使用反射嘗試,記錄此應用打開的鏈接端口,到數據庫端過濾,在執行解鎖)

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

須要工具檢測

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

Classloader?? Resin  glassfish等web服務器檢測...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等