本文详细描述了作者在处理一个线上JAVA定时任务服务挂掉的问题，发现是由于log4j2异步打日志时，Disruptor的Ringbuffer满导致死循环，CPU跑满，服务挂掉。经过排查，确认是log4j2和kafka的元数据更新引发的死锁。最终解决方案是设置队列满时的处理策略为丢弃，避免死循环。此外，还提到了xxl-job线程数增长的问题，与jetty服务器的默认线程池配置有关。
作者：IKNOW本尊
问题背景
收到频繁的告警邮件，定时任务调度失败，查看xxl-job的执行器列表是空的，但是服务又显示健康，查看历史任务执行记录发现执行器是依次递减，由于是线上服务，只能先重启，然后线程日志也没有，同时尝试访问服务的健康检查接口，发现健康检查接口访问不通，应该是服务已经挂了，但是因为服务配置的TCP健康检查，没鲸云没有检测出来服务异常(血淋淋的教训)。
总结问题现象：xxl-job的执行器列表为空，TCP检测正常，服务显示正常，但是http健康检查接口访问不了，服务其实处于挂掉状态。
初步排查过程:
1.查看线上的APM，发现两个异常:
堆内存会定期处于打满的状态 (被打满的都是 Eden Space----校长的定时任务计算任务很大，打满也是正常的，而且看了GC次数，young GC 和 old GC也没有太大异常)-----挂掉的时刻和正常情况的堆内存几乎是相同的规律，dump出现上的内存后，查看也没有什么问题，暂时排除是内存问题导致
发现重启的服务线程池一直在缓慢的增长，不是很理解，正常的线程池不会一直处于增长的状态，而且增长的数量也很大
2.进入终端，用arthas查看服务器线程状态
arthas 进入终端，执行thread命令 确实发现很多的线程处于WATING状态，dump出线程堆栈，发现有200多个线程处于WATING状态。
3.arthas 查看WATING状态的线程堆栈, 发现所有线程都处于下面的堆栈，看不出什么太多的线索，代码中查看是不是有什么地方设置了无限线程的线程池，发现也没有这么挫的操作。
4.张师傅注入线程的init方法, 发现是xxl-job的线程
[
最低0.47元/天 解锁文章
5368
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
