在生产环境中,CPU飙高是最常见、也最容易引发连锁故障的问题@mikechen
第一步:先看进程级别。
用 top 、或监控确认是哪个进程把 CPU 打满。

Linux 第一件事:
top
例如:
top
Cpu(s): 98% us
重点关注:
load average
Cpu
PID
%CPU
例如:
PID USER %CPU COMMAND
32451 java 389 java
说明:
CPU 已经被 Java 进程吃满。
第二步:看线程级别。
用 top -Hp <pid> 或类似工具找出最忙的线程,再把线程 ID 转成 16 进制,配合 jstack 定位到具体线程栈 。

继续:
top -Hp 32451
数含义: -H 显示线程(Threads),-p 指定进程 PID。
结果:
PID %CPU
32562 99.9
32568 98.7
32575 95.1
这里就定位到了:CPU 高的是线程,而不是整个 JVM。
第三步:找到对应 Java 代码。

Linux 给的是:
32562
但是:
jstack 输出的是:
nid=0x7f32
怎么办?
需要转换:
printf "%x\n" 32562
得到:
7f32
然后:
jstack 32451 > stack.log
搜索:
nid=0x7f32
立即就能找到:
at com.demo.OrderService.calculate()
at com.demo.OrderService.run()
at java.lang.Thread.run()
这就是:
CPU 最高线程正在执行的代码。
总而言之,线上CPU飙高的排查,本质上是一场与时间赛跑的系统化分析。
只有建立清晰的排查路径,熟练使用系统与应用层工具,并结合业务场景理解异常成因,才能在最短时间内定位根因。