top -h 可定位高 cpu 的 os 线程 pid，需转为十六进制后用 jstack 匹配 nid；若未匹配则线程可能已退出或为 gc 线程，应结合 jstat -gc 分析；jstack 仅拍快照易遗漏瞬时问题，推荐 pidstat 或 async-profiler；注意 safepoint 影响及 native 层问题需 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 <java-pid> | grep -A 10 "nid=0x3039"</java-pid> - 如果没匹配上，大概率是线程已退出，或 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 迷惑——这些是正常阻塞；真要盯的是连续多帧都在同一行、或反复调用同个工具方法的栈。
立即学习“Java免费学习笔记（深入）”；
为什么 jstack 有时抓不到高 CPU 线程？
不是 jstack 失效，是它只拍快照，而高 CPU 线程可能一闪而过。尤其当问题是周期性毛刺（比如每分钟一次的定时任务触发死循环），单次 jstack 很容易错过。
- 用
pidstat -t -p <pid> 1 30</pid>每秒采样 30 次，导出 CSV 后看线程 CPU 波峰对应的时间点 - 配合
async-profiler录制 CPU 火焰图：./profiler.sh -e cpu -d 30 -f /tmp/flame.svg <pid></pid>，比 jstack 更准、不依赖线程状态 - 注意 JDK 版本：JDK 8u60+ 才支持
jstack -l显示锁信息；老版本看不到waiting to lock细节
线上不敢随便 jstack？得控制影响范围
jstack 对 JVM 是安全的，但频繁执行或对大堆进程（>10G）执行，会触发 safepoint，导致所有线程停顿——表现为接口 RT 突增、心跳超时、甚至注册中心掉线。
- 单次执行加
-l和-F（强制）非常危险，仅限进程无响应时用；日常排查禁用-F - 避免在高峰期跑：
jstack <pid> > /tmp/jstack.out 2>&1</pid>，重定向输出，别让终端卡住 - 更轻量替代：
jcmd <pid> VM.native_memory summary</pid>查内存分配热点，或jstat -gc <pid></pid>看 GC 是否异常频繁
最常被忽略的一点：很多“CPU 高”其实是 native 层问题，比如 JNI 调用的 C 库死循环、Log4j2 的异步日志队列满后退化为同步刷盘、甚至容器 cgroup 限制导致线程调度失衡——这时候 jstack 根本看不出问题，得切到 perf top -p <pid></pid> 或 strace -p <pid></pid> 看系统调用热点。
