CPU过高怎么查？top和jstack排查指南

当Java应用出现CPU过高问题时，不能只盯着Java进程本身，而要从操作系统线程层面精准定位——先用`top -H`找出高CPU的OS线程PID，再转为十六进制后通过`jstack`匹配nid，但需警惕线程已退出、GC线程干扰或safepoint停顿带来的误判；面对瞬时毛刺，单次`jstack`极易遗漏，推荐`pidstat`持续采样或`async-profiler`生成火焰图；更关键的是，许多“CPU高”实为native层隐患（如JNI死循环、日志同步刷盘、cgroup调度失衡），此时必须借助`perf`或`strace`深入系统调用层，才能真正拨开迷雾、直击根因。

top -H 看出哪个线程在吃 CPU

Java 进程本身 CPU 高，不代表 Java 代码有问题——得先确认是哪个 OS 线程在狂跑。top -H 是第一步，它把线程（LWP）按 CPU 占用从高到低列出来。注意切换到线程视图后按 P（大写）可以按 CPU 排序，别用 T（那是按运行时间）。找到那个 %CPU 持续 90+ 的 pid，记下来，比如 12345。

常见错误：直接对 Java 进程 PID 执行 jstack，但没把线程 ID 转成十六进制——JVM 线程栈里显示的是 16 进制的 nid，而 top -H 给的是十进制。漏这步就对不上号。

• printf "%x\n" 12345 → 得到 3039
• 再搜 jstack | grep -A 10 "nid=0x3039"
• 如果没匹配上，大概率是线程已退出，或 GC 线程（如 G1 Conc#0）临时飙高，需结合 jstat -gc 看是否正在频繁 CMS/G1 并发阶段

jstack 输出里怎么快速定位可疑线程栈

jstack 日志里真正有用的不是“RUNNABLE”状态本身，而是它卡在哪一行、调了什么、有没有死循环或同步争用。重点关注三类栈：

• 无限循环体：比如 while (true) { ... } 且没 sleep/condition wait
• 同步块内耗时操作：比如 synchronized (obj) { httpClient.execute(...) } —— 锁住别人还自己慢
• 正则或 JSON 解析卡住：像 Pattern.compile(".*+.*") 这种灾难性正则，或 ObjectMapper.readValue() 解析超大字符串

别被 java.lang.Thread.sleep 或 Unsafe.park 迷惑——这些是正常阻塞；真要盯的是连续多帧都在同一行、或反复调用同个工具方法的栈。

为什么 jstack 有时抓不到高 CPU 线程？

不是 jstack 失效，是它只拍快照，而高 CPU 线程可能一闪而过。尤其当问题是周期性毛刺（比如每分钟一次的定时任务触发死循环），单次 jstack 很容易错过。

• 用 pidstat -t -p 1 30 每秒采样 30 次，导出 CSV 后看线程 CPU 波峰对应的时间点
• 配合 async-profiler 录制 CPU 火焰图：./profiler.sh -e cpu -d 30 -f /tmp/flame.svg ，比 jstack 更准、不依赖线程状态
• 注意 JDK 版本：JDK 8u60+ 才支持 jstack -l 显示锁信息；老版本看不到 waiting to lock 细节

线上不敢随便 jstack？得控制影响范围

jstack 对 JVM 是安全的，但频繁执行或对大堆进程（>10G）执行，会触发 safepoint，导致所有线程停顿——表现为接口 RT 突增、心跳超时、甚至注册中心掉线。

• 单次执行加 -l 和 -F（强制）非常危险，仅限进程无响应时用；日常排查禁用 -F
• 避免在高峰期跑：jstack > /tmp/jstack.out 2>&1，重定向输出，别让终端卡住
• 更轻量替代：jcmd VM.native_memory summary 查内存分配热点，或 jstat -gc 看 GC 是否异常频繁

最常被忽略的一点：很多“CPU 高”其实是 native 层问题，比如 JNI 调用的 C 库死循环、Log4j2 的异步日志队列满后退化为同步刷盘、甚至容器 cgroup 限制导致线程调度失衡——这时候 jstack 根本看不出问题，得切到 perf top -p 或 strace -p 看系统调用热点。

本篇关于《CPU过高怎么查？top和jstack排查指南》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！