JVM内存、CPU占用过高问题定位

---

前言

如果开发过程中代码存在不规范漏洞，Java程序在运行时就很有可能会出现：内存（溢出、泄漏）、CPU占用过高。本篇文章将通过一个简单的例子给大家演示一下，如果线上出现以上问题我们可以如何精准定位到代码上的问题。

排查思路：进程->线程->代码->类->方法

---

一、示例代码

模拟一个线程往一个集合List<byte[]> list中无限循环添加byte[]，这样就可以有效的观察到java进程运行时会出现CPU、内存占用过高的场景。然后给当前运行的线程自定一个线程名称，便于后续问题排查。

package com.nb.java;

import java.util.ArrayList;
import java.util.List;

@SpringBootApplication
public class JavaBasisApplication {
	public static void main(String[] args) {
		// 定义一个list
		List<byte[]> list = new ArrayList<>();
        // 创建一个线程，并且自定义这个线程的名称：模拟Java运行时CPU、内存占用过高的线程
		new Thread(() -> {
			while (true){ 
				System.out.println("===每次添加一个byte[10]字节数组===");
				list.add(new byte[10]);
			}
		},"模拟Java运行时CPU、内存占用过高的线程").start();
	}
}

二、运行代码

1、将上面的类基于SpringBoot打包成一个jar包，随便放到一个服务器运行。执行以下命令：

nohup java -jar java.jar > test.log 2>&1 &

2、查询当前运行的java程序进程PID：882245

jps -l

三、top命令

• CPU=262.4%
• MEM=5.3%

通过top命令可以发现882245这个进程（也就是我们运行的这个java程序）占用的CPU和内存相对来说都是比较高的。

四、问题定位

1、查看java进程所有的线程列表

top -p 882245 -H

从这个图可以看出我们运行的java程序里出现了882292线程占用CPU、内存过高。到这里我们就成功了一半。至少看到了是那个线程出现的问题。

2、输出线程882292十六进制

printf "%x\n" 882292

d7674（882292的十六进制的值，用于后面查看线程堆栈中的关键字检索）

五、输出java堆栈信息

注意：这里的882245是进程ID，不是线程ID。

jstack 882245 > pid_882245_dump.txt 

在当前目录会生成一个pid_882245_dump.txt 文件。

六、pid_882245_dump.txt

cat pid_882245_dump.txt | grep d7674 -B 30 

这里的（d7674）就是第四部生成的。

root@yiliao:~# cat pid_882245_dump.txt | grep d7674 -A 30 
"模拟Java运行时CPU、内存占用过高的线程" #31 prio=5 os_prio=0 cpu=1117037.88ms elapsed=1168.34s tid=0x00007efd81e31000 nid=0xd7674 runnable  [0x00007efd1c327000]
   java.lang.Thread.State: RUNNABLE
	at java.io.FileOutputStream.writeBytes(java.base@11.0.19/Native Method)
	at java.io.FileOutputStream.write(java.base@11.0.19/FileOutputStream.java:354)
	at java.io.BufferedOutputStream.flushBuffer(java.base@11.0.19/BufferedOutputStream.java:81)
	at java.io.BufferedOutputStream.flush(java.base@11.0.19/BufferedOutputStream.java:142)
	- locked <0x0000000413bcfa60> (a java.io.BufferedOutputStream)
	at java.io.PrintStream.write(java.base@11.0.19/PrintStream.java:561)
	- locked <0x00000004119f6828> (a java.io.PrintStream)
	at sun.nio.cs.StreamEncoder.writeBytes(java.base@11.0.19/StreamEncoder.java:233)
	at sun.nio.cs.StreamEncoder.implFlushBuffer(java.base@11.0.19/StreamEncoder.java:312)
	at sun.nio.cs.StreamEncoder.flushBuffer(java.base@11.0.19/StreamEncoder.java:104)
	- locked <0x00000004119f67e0> (a java.io.OutputStreamWriter)
	at java.io.OutputStreamWriter.flushBuffer(java.base@11.0.19/OutputStreamWriter.java:181)
	at java.io.PrintStream.write(java.base@11.0.19/PrintStream.java:606)
	- eliminated <0x00000004119f6828> (a java.io.PrintStream)
	at java.io.PrintStream.print(java.base@11.0.19/PrintStream.java:745)
	at java.io.PrintStream.println(java.base@11.0.19/PrintStream.java:882)
	- locked <0x00000004119f6828> (a java.io.PrintStream)
	at com.nb.java.JavaBasisApplication.lambda$main$0(JavaBasisApplication.java:30)
	at com.nb.java.JavaBasisApplication$$Lambda$634/0x00000008403d2c40.run(Unknown Source)
	at java.lang.Thread.run(java.base@11.0.19/Thread.java:829)

"DestroyJavaVM" #32 prio=5 os_prio=0 cpu=2896.41ms elapsed=1168.34s tid=0x00007efd80015000 nid=0xd7646 waiting on condition  [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Attach Listener" #33 daemon prio=9 os_prio=0 cpu=1.12ms elapsed=18.83s tid=0x00007efd18001000 nid=0xd76d7 waiting on condition  [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"VM Thread" os_prio=0 cpu=781.96ms elapsed=1171.43s tid=0x00007efd802a6000 nid=0xd764c runnable

从图上下面的剪头指向就很写清楚定位到：com.nb.java.JavaBasisApplication#main方法有问题。这样就定位到我们的具体代码。