程序员最不愿见到的就是程序抛出异常
经常会做些激进的测试,然后各种各样的异常都会抛出来
用户量增多,并发量加大如果没有去加以控制会发生一堆让你头疼的问题.
如:
cpu 达到100%,
占用内存增大,垃圾回收时间增长,jvm卡顿
流量增大,
线程安全/阻塞
数据库线程池耗尽,获取不到连接 抛出一些异常.这些异常然后会导致业务出现异常,然后数据出现错误.
并发量增加,大量的单例模式导致 业务层面的线程安全问题凸显
还有的破坏性测试,结果发现业务数据会出现混乱
一堆喜闻乐见的问题.
现在,我们来处理这些问题:
1.数据库连接池获取连接超时
假如数据库连接池设定的是2个,获取连接超时时间为6秒,有3条sql同时被执行.那么其中2条会正常的执行,第三条则等待前两条sql执行完毕,如果是这样就不会有问题.但是实际上第三条也在执行,这个时候这条sql也在尝试获取连接,并且开始计时.如果6秒后还没获取到连接就会抛出获取连接失败的异常.
如果你没有处理sql超时的问题,最好是不要设置超时时间.因为抛出异常后会导致业务数据出错.
应该插入的没插入,应该update的没update. 当然如果有很多业务,那么会导致其他业务都阻塞起来.
我觉得,这件事情嘛.就随他去好了!谁叫你弄那么多超出处理能力的业务呢!
另外一种方法就是上层控制,就好像做个大坝把水拦起来.
2.cpu100%
如果不是bug,业务量增大cpu必然会上升接近100%.jdk里面有很多监控工具. 还有性能分析工具.这个问题就对着分析工具一个方法一个方法的排查吧
3.流量增大
流量似乎不是个问题,但是看着监控软件几M几M的进进出出 还是有些担心.高访问量io操作增加,编解码压力增大.会导致cpu增高,垃圾回收的任务加大. 编解码处理能力达到上限,业务访问照成延迟.这个问题,也只能一点点优化了.
4.线程安全/阻塞
线程安全问题似乎无解,为了保证业务线程安全.该加的锁不会少.当然能不加的锁不要加.影响是非常恶劣的.
另外,业务间的线程安全问题是个更棘手更难处理的问题.在暴力测试下你才会重视这种事情
5.jvm卡顿
没有细致的研究过
