物联网项目一个死循环导致的事故,一次惨痛的教训

旧业务不断的调整,新的需求不断的开发,版本不断的迭代,这个是当前项目的一个暂时不可改变的现状。再加上每个开发人员写代码的风格和层次不一样,所以有很多本来可以在写代码过程中避免的问题非要通过线上的报警才能发觉。

最近两天线上linux服务器发现java进程CPU不断的飙升,新发的包过一会儿CPU就慢慢上涨,感觉很奇怪,之前没有这种情况,应该开发人员新写的代码所导致,排查问题如下:

一 使用top命令

使用top命令

jkkll888.png

结果如下:

114054_Sq5z_3724481_1.png

过了一会儿,继续top查看

114141_Xtic_3724481_2.png

114228_yVJk_3724481_3.png

二 查询具体的线程CPU占用率

使用命令 ps -mp 5910 -o THREAD,tid,time

fdgdfgfdg999.png

结果如下:

114420_G41V_3724481_4.png

可以看到5910号进程产生了大量的线程,继续查看该线程的具体执行情况。

先通过 printf "%xn" 18082拿到十进制

fgfgfgfgf111.png

结果是46a2

三 使用jstack查看具体线程

使用命令 jstack 5910 | grep 46a2-a 100

mhgmhgmgh222.png

发现如下:

114716_zhqH_3724481_5.png

找来开发人员一起仔细想想写的代码在什么地方用到了线程池之类的,果然真有这样的代码,一起喵了眼代码,发现了问题。

注:以下代码是模拟代码

342234321111.png

3243242222.png

dsdfsdfds3333.png

问题其实就在createTask的方法里面while (true)进入了死循环,不断的产生线程导致(前面的线程没释放,后面的不断在产生)。

其实事情到这里还未完,我看到代码里面有用到newCachedThreadPool,它是创建一个可缓存线程池,如果线程池长度超过处理需要,可灵活回收空闲线程,若无可回收,则新建线程。也就是说如果主线程提交任务的速度高于线程池中处理任务的速度时,CachedThreadPool会不断创建新线程。极端情况下,CachedThreadPool会因为创建过多线程而耗尽CPU资源。所以这块也需要注意先备注下后面再优化。

猜你喜欢

转载自blog.csdn.net/u010460625/article/details/108470096
今日推荐