Tomcat进程占用CPU过高怎么办？

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

在性能优化这个主题里前面我们聊过了Tomcat的内存问题和网络相关的问题接下来我们看一下CPU的问题CPU资源经常会成为系统性能的一个瓶颈这其中的原因是多方面的可能是内存泄漏导致频繁GC进而引起CPU使用率过高又可能是代码中的bug创建了大量的线程导致CPU上下文切换开销。

今天我们就来聊聊Tomcat进程的CPU使用率过高怎么办以及怎样一步一步找到问题的根因。

“Java进程CPU使用率高”的解决思路是什么

通常我们所说的CPU使用率过高这里面其实隐含着一个用来比较高与低的基准值比如JVM在峰值负载下的平均CPU利用率为40%如果CPU使用率飙到80%就可以被认为是不正常的。

典型的JVM进程包含多个Java线程其中一些在等待工作另一些则正在执行任务。在单个Java程序的情况下线程数可以非常低而对于处理大量并发事务的互联网后台来说线程数可能会比较高。

对于CPU的问题最重要的是找到是哪些线程在消耗CPU通过线程栈定位到问题代码如果没有找到个别线程的CPU使用率特别高我们要怀疑是不是线程上下文切换导致了CPU使用率过高。下面我们通过一个实例来学习CPU问题定位的过程。

定位高CPU使用率的线程和代码

1.写一个模拟程序来模拟CPU使用率过高的问题这个程序会在线程池中创建4096个线程代码如下

@SpringBootApplication
@EnableScheduling
public class DemoApplication {

   //创建线程池其中有4096个线程。
   private ExecutorService executor = Executors.newFixedThreadPool(4096);
   //全局变量访问它需要加锁。
   private int count;
   
   //以固定的速率向线程池中加入任务
   @Scheduled(fixedRate = 10)
   public void lockContention() {
      IntStream.range(0, 1000000)
            .forEach(i -> executor.submit(this::incrementSync));
   }
   
   //具体任务就是将count数加一
   private synchronized void incrementSync() {
      count = (count + 1) % 10000000;
   }
   
   public static void main(String[] args) {
      SpringApplication.run(DemoApplication.class, args);
   }

}

2.在Linux环境下启动程序

java -Xss256k -jar demo-0.0.1-SNAPSHOT.jar

3.使用top命令我们看到Java进程的CPU使用率达到了262.3%注意进程ID是4361.

4.接着我们用更精细化的top命令查看这个Java进程中各线程使用CPU的情况

#top -H -p 4361

从图上我们可以看到有个叫“scheduling-1”的线程占用了较多的 CPU达到了 42.5%。因此下一步我们要找出这个线程在做什么事情。

5.为了找到线程在做什么事情我们需要用jstack命令生成线程快照具体方法是

jstack 4361

jstack 的输出比较大你可以将输出写入文件

jstack 4361 > 4361.log

然后我们打开 4361.log定位到第 4 步中找到的名为“scheduling-1”的线程发现它的线程栈如下

从线程栈中我们看到了AbstractExecutorService.submit这个函数调用说明它是 Spring Boot 启动的周期性任务线程向线程池中提交任务这个线程消耗了大量 CPU。

进一步分析上下文切换开销

一般来说通过上面的过程我们就能定位到大量消耗 CPU 的线程以及有问题的代码比如死循环。但是对于这个实例的问题你是否发现这样一个情况Java 进程占用的 CPU 是 262.3% 而“scheduling-1”线程只占用了 42.5% 的 CPU那还有将近 220% 的 CPU 被谁占用了呢

不知道你注意到没有我们在第 4 步用top -H -p 4361命令看到的线程列表中还有许多名为“pool-1-thread-x”的线程它们单个的 CPU 使用率不高但是似乎数量比较多。你可能已经猜到这些就是线程池中干活的线程。那剩下的 220% 的 CPU 是不是被这些线程消耗了呢

要弄清楚这个问题我们还需要看 jstack 的输出结果主要是看这些线程池中的线程是不是真的在干活还是在“休息”呢

通过上面的图我们发现这些“pool-1-thread-x”线程基本都处于 WAITING 的状态那什么是 WAITING 状态呢或者说 Java 线程都有哪些状态呢你可以通过下面的图来理解一下

从图上我们看到“Blocking”和“Waiting”是两个不同的状态我们要注意它们的区别

Blocking 指的是一个线程因为等待临界区的锁Lock 或者 synchronized 关键字而被阻塞的状态请你注意的是处于这个状态的线程还没有拿到锁。
Waiting 指的是一个线程拿到了锁但是需要等待其他线程执行某些操作。比如调用了 Object.wait、Thread.join 或者 LockSupport.park 方法时进入 Waiting 状态。前提是这个线程已经拿到锁了并且在进入 Waiting 状态前操作系统层面会自动释放锁当等待条件满足外部调用了 Object.notify 或者 LockSupport.unpark 方法线程会重新竞争锁成功获得锁后才能进入到 Runnable 状态继续执行。

回到我们的“pool-1-thread-x”线程这些线程都处在“Waiting”状态从线程栈我们看到这些线程“等待”在 getTask 方法调用上线程尝试从线程池的队列中取任务但是队列为空所以通过 LockSupport.park 调用进到了“Waiting”状态。那“pool-1-thread-x”线程有多少个呢通过下面这个命令来统计一下结果是 4096正好跟线程池中的线程数相等。

你可能好奇了那剩下的 220% 的 CPU 到底被谁消耗了呢分析到这里我们应该怀疑 CPU 的上下文切换开销了因为我们看到 Java 进程中的线程数比较多。下面我们通过 vmstat 命令来查看一下操作系统层面的线程上下文切换活动

如果你还不太熟悉 vmstat可以在这里https://linux.die.net/man/8/vmstat学习如何使用 vmstat 和查看结果。其中 cs 那一栏表示线程上下文切换次数in 表示 CPU 中断次数我们发现这两个数字非常高基本证实了我们的猜测线程上下文切切换消耗了大量 CPU。那么问题来了具体是哪个进程导致的呢

我们停止 Spring Boot 测试程序再次运行 vmstat 命令会看到 in 和 cs 都大幅下降了这样就证实了引起线程上下文切换开销的 Java 进程正是 4361。