CPU 100% 先别重启：一套从 top 到 perf 火焰图的排查流程

生产环境的 CPU 打满，第一反应千万别是重启——重启能止血，但病根还在，下次照样打满。下面这套流程是排查这类问题的常用顺序，从粗到细、层层收敛。

一、先看是谁：top / htop

top 按大写 P 键按 CPU 排序，找到 %CPU 最高的进程，记下 PID。htop 更直观，能看到完整命令行，一眼认出是 java、python 还是 nginx worker。

二、再看是哪个线程：top -H / pidstat

很多时候是某个线程死循环。top -H -p <PID> 看线程级 CPU，或者 pidstat -t -p <PID> 1 3，直接揪出吃 CPU 的 TID。注意 pidstat 显示的是十进制 TID，转成十六进制才能去对 jstack。

三、分语言下钻

• Java：jstack <PID> > jstack.log，把高 CPU 的 TID 转 16 进制，在日志里搜 nid=0x...，直接看到卡在哪一行代码。
• Python：py-spy top --pid <PID>，实时看各函数耗时，不用改代码、不用重启。
• Go：go tool pprof 抓一份 profile，或直接看 /debug/pprof。
• C/C++ 这类 native 程序：直接上 perf。

四、上火焰图：perf

perf record -F 99 -p <PID> -g -- sleep 30 抓 30 秒采样，再用 FlameGraph 生成 SVG。火焰图一看：哪座"山"最宽，CPU 就去哪了。是业务死循环、GC，还是锁竞争，一目了然。

五、常见根因清单（按遇到频率排）

1. 死循环 / 正则灾难：回溯失控的正则能吃掉整整一个核。
2. GC 频繁：Java 老年代满了，jstat -gcutil 看 FGC 次数和耗时。
3. 锁竞争：线程都堵在锁上，CPU 高但吞吐低，jstack 里满屏的 BLOCKED。
4. 日志打太多：同步写日志在高并发下本身就是瓶颈。
5. 定时任务重叠：cron 配得太密，上一个还没跑完下一个又起了。

最后：动手修之前，先保留证据：top 输出、jstack 日志、火焰图，修完再对比。排查 CPU 问题，流程比工具重要——顺序对了，十分钟定位是常态。