测试代码如下:
@Controller
public class testController {
@PostMapping(value = "/testCpu")
public void newCpuHeigh() {
while (true) {
new Thread(() -> {
try {
Thread.sleep(1);
newCpuHeigh();
} catch (InterruptedException e) {
e.printStackTrace();
}
});
}
}
private static List<byte[]> LIST = new ArrayList<>(10240);
@PostMapping(value = "/testHeadOver")
private void headOver() {
int a = 1;
while (true) {
System.out.println("执行次数:" + (a++));
LIST.add(new byte[1024 * 1024 * 100]);
}
}
}
一:执行如上testCpu方法后,即刻关注运行情况:
1:top命令查看CPU占用情况,发现23375进程已经100%
2:执行: jmap -dump:live,format=b,file=live_ccc23375_dump.hprof 23375 生成内存dump文件,进行离线分析
下面用MemoryAnalyzer工具打开进行分析:
很详细的就显示了,选择 with incoming references
二: 执行如上testHeadOver方法后,即刻关注运行情况:
也关注到FGC在慢慢变大:
同上执行:jmap -dump:live,format=b,file=live_ccc25688_dump.hprof 25688
找到对应的 List<byte[]>:
以上都是手动执行,也可以配置jvm参数:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/home/logs/dump.hprof
排查命令总结(参考:Java线上CPU内存冲高问题排查步骤)
-
top
:查看系统进程CPU与内存占用情况,找到占用最多的进程ID -
top -Hp 进程号
:查看该进程号的所有线程CPU与内存占用情况,找到占用最多的线程ID(显示的PID即为10进制线程编号,printf "%x\n" 进程号转为16进制线程号) -
jstack 进程号 > stack.txt
:将进程号所属进程的堆栈信息输出到stack.txt中 -
jstack 进程号 | grep 16进制线程号
:查看进程号先所属线程的堆栈信息,可查看线程名,区分出普通线程与GC线程("VM Thread")。 -
jstat -gcutil 进程号 统计间隔毫秒 统计次数(缺省代表一直统计)
:如果是因为GC问题,进一步观察GC情况 -
jmap -heap 进程ID
:查看详细进程内存使用信息 -
jmap -dump:format=b,file=文件名称 进程ID
:将进程内存信息dump到磁盘上供进一步分析。 -
java -Xmx4G -jar ha457.jar
:使用ha457.jar来分析内存泄漏情况。
异常情况解决总结
-
GC问题:top+top -Hp + jstack排查是"VM Thread"消耗过多资源,可以进一步使用jmap工具进行内存溢出排查。
-
业务执行过慢问题:top+top -Hp + jstack排查发现是普通业务线程,可看到具体是哪个接口。
-
死锁:
jstack + Java进程
打印堆栈信息中包含死锁信息deadlock -
线程处于waiting状态:多打印几次jstack信息,对比一直停留在waiting状态的线程