Linux CPU飙高排查实战：从top到perf的完整定位路径

一、先分清两个指标：load average 与 CPU 使用率

排查第一步不是急着敲 top，而是先弄清楚“飙高”到底是哪一个：load average 反映的是运行队列与不可中断（D 状态）任务的长度，CPU 使用率才是真正的计算开销。如果 1 分钟负载远高于核数而 CPU 使用率并不高，问题多半出在 IO 阻塞或大量 D 状态进程上，排查方向就完全不同了。

uptime
# load average: 24.10, 18.32, 9.05  → 8 核机器，负载 24 明显过载

二、定位到进程，再下钻到线程

top 里按大写 P 以 CPU 排序找到可疑进程后，记住两个常用参数：-H 直接显示线程，-p 只盯目标进程。Java 类应用尤其要下钻到线程，拿到线程 TID 后用 printf 转成十六进制，才能和 jstack 输出里的 nid 对上号。

top -Hp 12345
printf "%x\n" 23418   # 线程 TID 转十六进制
jstack 12345 | grep -A 20 nid=0x5b7a

三、看 us 与 sy 的比例，区分用户态和内核态

vmstat 1 的持续输出里，us 高说明业务代码本身在烧 CPU（算法复杂度、序列化、正则回溯）；sy 高则多半是系统调用频繁、锁竞争或缺页中断；wa 高是 IO 等待；si/so 持续非零说明内存吃紧已经开始换页。mpstat -P ALL 1 可以逐核观察，判断是否被打满的只是个别核，这对定位绑核不当的进程特别有用。

vmstat 1
# r 列远大于核数 → 计算过载；b 列大 → IO 阻塞多
mpstat -P ALL 1

四、最后一公里：perf 采样与火焰图

确定了进程与方向仍找不到根因时，用 perf 对目标进程采样，火焰图里最宽的调用栈就是热点函数。没有图形环境时，perf top 也能直接看热点符号。

perf top -p 12345
perf record -F 99 -p 12345 -g -- sleep 30
perf script | stackcollapse-perf.pl | flamegraph.pl > hot.svg

五、小结

整条链路可以归纳为一句话：先用负载判断方向，再用 top -H 锁定线程，用 vmstat 区分用户态与内核态，最后用 perf 落到具体函数。绝大多数 CPU 飙高问题，都能在这四步之内收敛到根因。