Atitit.软件开发提高稳定性总结

Atitit.软件开发提高稳定性总结php

 

#----影响稳定性几个类别 3java

1. 资源和内存泄漏溢出 3python

2. 数据库/文件死锁 3c++

3. 类库冲突 3web

4. 热更新热部署(业务可用性 3数据库

5. 程序崩溃 3编程

6. 磁盘空间/cpu/内存占用太高 3api

#-----影响稳定性的因素 3缓存

7. 内存泄漏溢出 3ruby

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  glassfishwebserver检測...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本身主动恢复脚本..

PRPGRAMCS内要TRY CATCH,发现主程序出问题,从新启动。

PROGRAME。CS内添加UnhandledException 的捕获..

 

 

45. 日志,缓存等文件。尽量按时间生成多个文件。

可以防止万一个哪一个文件句柄没被释放,也不会影响后面的文件写入。

 

46. 重要业务服务和页面gui监測

可以及时发现服务out service

 

47. 监測程序(cpu,内存占用, io队列深度磁盘空间,数据库链接数,数据库死锁监測)

提早发现不稳定性因素...

48. 网络,文件操做使用wrap类库secury方式调用

默认的sdk库使用必定要TRYCATCH。

 

49. 死锁自解除(数据库,文件等)

 

#----压力測试

当前项目尽管并发不大(当前200左右,默认的配置可支持5000左右)...

但是压力測试可以提早測试出稳定性方面的问题..

 

经常使用工具jmeter,LoadRunner等

相关文章
相关标签/搜索