#----影响稳定性几个类别 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:[email protected]
转载请注明来源： 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等