诊断Java线程池CPU100%死循环的绝技

在实际线上环境中，Java线程池导致CPU使用率达到100%的死循环问题是一个棘手的挑战。本文详细介绍了如何诊断和解决这个问题。首先，我们会将有问题的容器下线，并使用top和jstack命令分析线程运行情况，发现高CPU使用率的线程是由线程池创建的。进一步的分析显示，线程池中的大量线程处于runnable状态，尝试获取任务却未执行任何任务。通过生成Java进程的火焰图，我们发现CPU主要消耗在LinkedBlockingQueue.poll方法上，怀疑是线程池配置问题导致的。我们尝试了调整线程池参数、更换队列类型等解决方法，并提供了详细的排查和解决步骤。

如何诊断Java ThreadPoolExecutor导致CPU使用率100%的死循环问题？

在实际的线上环境中，我们可能会遇到一个服务的容器突然告警，显示CPU使用率达到100%。为了确保系统的安全，我们首先会将有问题的容器下线，防止新的流量进入。然而，即使在没有请求流量的情况下，容器中Java进程的CPU使用率仍然居高不下。

接下来，我们通过登陆容器并使用top命令来查看各个线程的运行情况，发现CPU使用率高的线程是由线程池创建的。令人奇怪的是，容器下线后不应再有请求触发线程池执行任务。使用jstack命令列出各个线程的堆栈，我们发现线程池中共有64个线程，其中40个线程处于等待获取新任务的状态，24个线程处于runnable状态。

这些处于runnable状态的线程堆栈显示，它们也在尝试获取任务，但实际上并没有线程在执行任务。这非常不寻常，因为线程池中的线程应该快速查询是否有任务可用，获取到任务后执行任务中的代码，或者因为拿不到任务而进入等待状态。极少情况下，线程会处于runnable状态并试图获取任务，但不会有40%左右的线程都处于这种状态。

为了进一步分析，我们生成了Java进程的火焰图，发现CPU主要消耗在LinkedBlockingQueue.poll方法上，这与jstack的信息一致。我们开始怀疑是否是线程池配置的问题，导致线程不断轮询任务队列而没有进入等待状态。我们的线程池配置为maxPoolSize为64，corePoolSize为16，目前线程池中的线程数量达到了最大值64。我们还配置了keepAliveTime参数为60秒，这意味着如果线程在60秒内没有获取到任务，它将被终止，直到线程数量减少到corePoolSize。使用arthas查看LinkedBlockingQueue.poll的调用情况，但没有发现频繁的调用。这让我们的排查思路陷入困境，只能怀疑LinkedBlockingQueue.poll方法可能存在某种bug，导致获取不到任务时进入死循环。但考虑到我们使用的是zulu-17版本的JDK，这种显著的bug不太可能存在。

根据现有信息，我们推测问题可能出在poll()方法调用时需要获取takeLock。当大量线程同时调用poll()时，锁竞争不可避免。在这个过程中，没有获取到锁的线程会进行自旋等待操作，导致CPU使用率升高（仍然是RUNNABLE状态），这也使得keepAliveTime失效，无法回收线程。

我们可以尝试以下解决方法：

1. 将maxPoolSize从64调整到32，这样可以减少线程池中的线程数量，降低锁竞争。
2. 尝试更换队列类型，比如使用ArrayBlockingQueue，这可能减少锁竞争的开销，尽管吞吐量可能会有所下降。
3. 排查代码，确认是否有提交了死循环任务的可能性。
4. 尝试更换JDK版本，看是否能解决问题。
5. 检查容器资源分配是否足够，可能资源不足也会导致高CPU使用率的问题。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《诊断Java线程池CPU100%死循环的绝技》文章吧，也可关注golang学习网公众号了解相关技术文章。