java 线程池导致cpu占用100%的原因及排查方法
近日，我们在线上服务中发现了一个容器的cpu使用率突然达到100%，为了保障系统的稳定性，我们首先将该容器下线，停止新的流量进入。然而，即使没有新的请求，容器中的java进程cpu使用率依然居高不下。随后，我们通过top命令检查各个线程的使用情况，发现高cpu占用的线程是由线程池创建的。
这引发了我们的疑问：既然容器已经下线，为何线程池还会持续执行任务？接着，我们使用jstack命令查看各个线程的堆栈情况，发现线程池中有64个线程，其中40个线程处于等待新任务的状态（waiting），而另外24个线程则处于可运行状态（runnable）。具体的可运行线程堆栈信息如下：
<code>"pool-1-thread-1" prio=10 tid=0x00007f9f5c01e800 nid=0x1a runnable [0x00007f9f54527000]
java.lang.Thread.State: RUNNABLE
at java.base/java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:464)
at java.base/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1056)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1118)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)</code>从堆栈信息可以看出，这些可运行的线程正在尝试获取任务，但实际上并没有线程在执行任务。这非常奇怪，因为线程池中的线程在查询是否有新任务的操作应该非常快且短暂。理论上，线程池中的线程应该要么获取任务并执行任务中的代码，要么因为没有任务而陷入等待状态（waiting），只有极少数情况下会处于可运行状态并试图获取任务。不可能有40%的线程都处于这种状态。
为了进一步了解情况，我们生成并分析了Java进程的火焰图，发现CPU主要消耗在LinkedBlockingQueue.poll方法上，这与jstack的信息一致。我们开始怀疑可能是线程池的配置问题，导致线程不断轮询任务队列而无法进入等待状态（waiting）。经确认，我们的线程池配置了maxPoolSize为64，corePoolSize为16，当前线程池中的线程数量达到了最大值64。线程池还配置了keepAliveTime参数为60秒，这样如果线程在60秒内没有获取到任务，它会等待60秒钟，如果仍然没有任务，线程将终止直到线程数量减少到corePoolSize。我们使用Arthas查看LinkedBlockingQueue.poll的调用情况，但并没有发现它被频繁调用。
在这一步，我们的思路陷入了停滞，目前只能怀疑LinkedBlockingQueue.poll方法存在某些bug，导致获取不到任务时会陷入死循环。但考虑到这是JDK内部的代码，这种明显的bug应该是不太可能的。我们使用的JDK版本是zulu-17。是否有其他人遇到过类似的问题，提供一些提示和方向呢？
立即学习“Java免费学习笔记（深入）”；
根据现有的信息，我们可以推测在调用poll()方法时需要获取takeLock。当大量线程同时调用poll()时，锁竞争不可避免。在这个过程中，没有获取到锁的线程会进行自旋等待操作，从而导致CPU占用率升高（仍然处于RUNNABLE状态），这也会使keepAliveTime失效，无法回收线程。
我们可以查看LinkedBlockingQueue.poll方法的实现：
<code>public E poll(long timeout, TimeUnit unit) throws InterruptedException {
final E x;
final int c;
long nanos = unit.toNanos(timeout);
final AtomicInteger count = this.count;
final ReentrantLock takeLock = this.takeLock;
takeLock.lockInterruptibly();
try {
while (count.get() == 0) {
if (nanos 1)
notEmpty.signal();
} finally {
takeLock.unlock();
}
if (c == capacity)
signalNotFull();
return x;
}</code>基于以上分析，我们可以尝试以下几种解决方案：
- 调整线程池大小：将maxPoolSize从64调整到32，这样可以减少锁竞争。
- 更换队列类型：尝试使用ArrayBlockingQueue，这种队列的锁竞争开销较小，虽然吞吐量可能会有所下降。
- 排查代码：检查是否有提交了死循环任务，导致线程池中的线程无法正常结束。
- 更换JDK：尝试使用其他版本的JDK，看是否能解决问题。
- 检查容器资源分配：确保容器的资源分配充足，避免因资源不足导致的性能问题。
