本文主要是介绍物联网项目一个死循环导致的事故,一次惨痛的教训,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
旧业务不断的调整,新的需求不断的开发,版本不断的迭代,这个是当前项目的一个暂时不可改变的现状。再加上每个开发人员写代码的风格和层次不一样,所以有很多本来可以在写代码过程中避免的问题非要通过线上的报警才能发觉。
最近两天线上linux服务器发现java进程CPU不断的飙升,新发的包过一会儿CPU就慢慢上涨,感觉很奇怪,之前没有这种情况,应该开发人员新写的代码所导致,排查问题如下:
一 使用top命令
使用top命令
结果如下:
过了一会儿,继续top查看
二 查询具体的线程CPU占用率
使用命令 ps -mp 5910 -o THREAD,tid,time
结果如下:
可以看到5910号进程产生了大量的线程,继续查看该线程的具体执行情况。
先通过 printf "%xn" 18082拿到十进制
结果是46a2
三 使用jstack查看具体线程
使用命令 jstack 5910 | grep 46a2-a 100
发现如下:
找来开发人员一起仔细想想写的代码在什么地方用到了线程池之类的,果然真有这样的代码,一起喵了眼代码,发现了问题。
注:以下代码是模拟代码
问题其实就在createTask的方法里面while (true)进入了死循环,不断的产生线程导致(前面的线程没释放,后面的不断在产生)。
其实事情到这里还未完,我看到代码里面有用到newCachedThreadPool,它是创建一个可缓存线程池,如果线程池长度超过处理需要,可灵活回收空闲线程,若无可回收,则新建线程。也就是说如果主线程提交任务的速度高于线程池中处理任务的速度时,CachedThreadPool会不断创建新线程。极端情况下,CachedThreadPool会因为创建过多线程而耗尽CPU资源。所以这块也需要注意先备注下后面再优化。
这篇关于物联网项目一个死循环导致的事故,一次惨痛的教训的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!