线程池使用不规范导致的生产问题
一 现象
线上环境卡顿,k8s探针接口无响应,导致服务假死
二 紧急处理方案
在nacos上把有问题的节点紧急下线,切走流量,保留k8s有问题节点,通过jstack pid 导出jvm线程池现状
三 问题分析
系统实现线程池有400个core线程数,任务队列 new ArrayBlockingQueue(2000);
处于waiting状态的线程数刚好400个,代表核心线程的400个线程全部满了卡住了
而代码中新的事件一直在发布然后调用线程
数据量大的情况会出现如下图情况
四 代码修改及规范
父子任务,存在等待关系的任务不应该用同一个线程池,规范每个服务的线程池的实现及使用
五 为什么线程池卡死带导致线上请求也卡死
线程池的卡死本质是因为新增业务编码规则需要计算,现上有新增的操作,也会卡死,导致tomcat负责处理请求的线程慢慢卡住并且占满,
所以k8s探针请求没有空余的线程去处理,但是k8s认为你的服务有问题需要重启,因为还没达到探针失败的次数阀值,所以从nacos上下线
是最快的解决方式,而且暂时保留了现场,在重启前将对应日志下下来分析原因
如果您喜欢此博客或发现它对您有用，则欢迎对此发表评论。 也欢迎您共享此博客，以便更多人可以参与。 如果博客中使用的图像侵犯了您的版权，请与作者联系以将其删除。 谢谢 ！