前言

在计算机操作系统中，CPU 是时分（time division）的，CPU 不会被同一个线程独占一直使用着，除非是那种非抢占式的。在操作系统中有很多线程，每个线程的运行时间由 CPU 决定，CPU 会分给每个线程一个时间片，时间片是一个极短的时间长度，如果在时间片内，线程一直占有，则认为是 CPU 100% 。CPU 运行速度很快，即主频非常高，除非密集型耗费 CPU 的运算，其它类型任务一般都会在小于时间片的时间内结束。

Java 进程 CPU 100% 的排查步骤，大体上都是差不多的，可能会根据不同场景有些命令稍有区别。

1. 首先找出消耗 CPU 最高的进程 PID。
2. 然后再根据进程 PID 找出进程内消耗 CPU 最高的线程号 TID。
3. 最后根据线程号 TID 找出对应的 Java 线程，进行排查处理。

正常情况下，我们一般将服务部署到 Linux 服务器上的，所以重点讲解在 Linux 服务器上的排查过程。不过考虑到，大多程序员是在 Windows 环境开发，或者有少数服务是部署到 Windows 服务器的，所以 Windows 和 Linux 两种环境都会讲解排查的过程。

测试样例

以下接口会不断循环创建 Person 对象，最终会产生内存溢出。

/*** @author 陈皮* @version 1.0* @description* @date 2022/4/19*/
public class ChenPiController {private final List<Person> persons = new ArrayList<>();@GetMapping("test")public void test() {int i = 1;while (true) {persons.add(new Person("张三", i++));System.out.println(persons.size());}}}

Windows 环境排查

首先找出消耗 CPU 最高的进程 PID。有两种方式可以查出，一种是通过 Windows 任务管理器，配合 CPU 列和 PID 列找出，CPU 列数字越大，代表消耗 CPU 越高，然后找出镜像名称是 java.exe 的，最后得出 PID。

另外一种方式是使用微软的工具Process Explorer，此软件不仅可以查看进程的情况，还能查看线程的 CPU 占有率，而任务管理器只能看到进程的 CPU 占有率。下载来解压就直接可以使用了。

下载地址：https://docs.microsoft.com/zh-cn/sysinternals/downloads/process-explorer

打开软件后，首先找出 cpu 占用率最高的 Java 进程，如下，进程号 PID 是16356。

然后右击此行数据，选择 Properties 打开，如下：

切换到 Threads 列页面。既可以看到此进程内的线程信息，并且发现 CPU 占用率最高的线程的 TID 是18240，6480，11260，13888，16312 等等。

打开 cmd 命令行工具，通过命令jstack 16356 > d:/16356.stack，将进程的堆栈信息导出到本地 D 盘的 16356.stack 文件中。注意，导出的文件位置随意，文件名一般以进程号+stack后缀组成，当然也可以其他后缀。

上面我们排查到 CPU 占用率最高的线程的 TID 是18240，6480，11260，13888，16312，这些数字是十进制的，而导出的堆栈信息里面的线程 ID 是十六进制的，所以我们需先转换为16进制，即 0x4740，0x1950，0x2bfc，0x3640，0x3fb8。

然后我们打开堆栈文件 16356.stack，在里面查找这些数字，首先是 0x4740，发现定位到我们程序的代码30行，经检测程序，原来是死循环不断的产生 Person 对象，故找到原因所在。

而且通过其他4个线程 ID 0x1950，0x2bfc，0x3640，0x3fb8，在堆栈文件中，发现是 GC 线程的 ID，从而也证明 GC 线程一直忙碌，表示内存不够用了，要进行内存回收，可能是 Java 内存回收不了，所以导致一直 gc，使 CPU 占用率极高。

至此，问题找到原因，原来是在死循环中，不断生产 Person 实例，并且无法回收，不仅工作线程一直占用 cpu，而且导致 gc 线程忙碌进行回收内存，但是回收不了，最后导致内存不足java.lang.OutOfMemoryError。

Linux环境排查

首先使用top命令找出 CPU 占用最高的进程。进程 PID 为 29869 。

再使用ps -ef | grep java或jps命令查看 CPU 占用高的进程是否为 Java 进程。

使用top -H -p pid命令查询此进程的所有线程情况，发现主要有三个线程（PID 为 29871，29872， 29873）CPU占用率高。-H 表示以线程的维度显示，默认以进程维度展示。

使用命令jstack pid > pid.tdump将此进程的线程栈导出到文件，并使用cat命令进行查看。文件后缀名随意，通常以tdump结尾即可。

jstack 29869 > 29869.tdumpcat 29869.tdump

将 前面查出的3个线程 PID 从10进制转为16进制，对应分别为 29871 -> 0x74af，29872 -> 0x74b0，29873 -> 0x74b1。

发现此3个线程中有2个为 gc 线程和1个工作线程。gc 线程忙碌表示内存不够用了，要进行内存回收，但是内存回收不了，导致一直 gc。

使用jstat -gcutil pid命令查看进程的堆情况，发现年轻代中 Eden 和老年代已使用的内存占当前容量百分比很高，并且 GC 频繁。

• S0：年轻代中第一个 survivor（幸存区）已使用的占当前容量百分比
• S1：年轻代中第二个 survivor（幸存区）已使用的占当前容量百分比
• E：年轻代中 Eden 区已使用的占当前容量百分比
• O：老年代已使用的占当前容量百分比
• M：元数据区使用比例
• CCS：压缩使用比例
• YGC：从应用程序启动到采样时年轻代中 gc 次数
• YGCT：从应用程序启动到采样时年轻代中 gc 所用时间（单位秒）
• FGC：从应用程序启动到采样时老年代 full gc 次数
• FGCT：从应用程序启动到采样时老年代 full gc 所用时间（单位秒）
• GCT：从应用程序启动到采样时 gc 用的总时间（单位秒）

使用jmap -dump:live,format=b,file=pid.hprof pid命令导出堆文件，只导出 live 存活的对象。文件后缀名可以是任意的，因为它也是二进制的，不过通常以 hprof 结尾。

最后使用 JDK 自带的工具，JAVA_HOME/bin/jvisualvm.exe工具分析快照。

操作路径：文件 -> 装入 -> 文件类型选择堆，选中刚才导出的堆文件。

选择类列表，按照大小排序，找出占用内存最大的类别，发现是 Person 类。

至此，问题找到原因，原来是在死循环中，不断生产 Person 实例，并且无法回收，不仅工作线程一直占用 CPU，而且导致 gc 线程忙碌进行回收内存，但是回收不了，最后导致内存不足java.lang.OutOfMemoryError。

最后简单总结下，上诉的排查过程不一定适用全部场景，不同大体上的思路大同小异。根据自己情况，使用不同的命令和工具进行分析，而且，Java 的 bin 目录下有很多 JVM 性能调优监控工具，如 jps，jstack，jmap，jhat，jstat，hprof。

---

本次分享到此结束啦~~

我是陈皮，一个在互联网 Coding 的 ITer。如果觉得文章对你有帮助，点赞、收藏、关注、评论，您的支持就是我创作最大的动力！