top -H 显示的线程 PID 是十进制，jstack 的 nid 是对应十六进制，需用 printf "%x" 转换后匹配；实操可用一行命令链自动完成筛选、转换与堆栈定位，并重点关注 RUNNABLE 状态及计算密集型堆栈。
top -H 看到的线程 PID 是十进制，但 jstack 输出的 nid 是十六进制
Linux top -H 默认显示的是线程的 LWP（Light Weight Process）ID，本质就是内核级线程 PID，单位是十进制。而 jstack 日志里每个线程的 nid 字段（如 nid=0x7b04）是十六进制，直接肉眼比对会错位。很多人卡在这一步——看到 top -H 里 CPU 占用 98% 的线程 PID 是 31492，却在 jstack 里翻遍也找不到 31492，其实它对应的是 0x7b04。
所以核心动作不是“找数字”，而是做一次进制转换：用 printf "%x" 31492 得到 7b04，再搜索 nid=0x7b04。
快速定位高 CPU 线程并关联到 Java 堆栈的实操链路
别反复切窗口、手输数字。把三步串成一行命令更可靠：
top -H -b -n1 | grep -E 'java.*[0-9]{2,}%' | head -1 | awk '{print $1}' | xargs printf "%x\n" | xargs -I{} grep -A 10 "nid=0x{}" /tmp/jstack.log说明：
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
top -H -b -n1：批处理模式只取一帧，避免交互干扰 -
grep -E 'java.*[0-9]{2,}%'：粗筛含 java 关键字且 CPU ≥ 10% 的行（防误匹配 1%、5% 这类噪声） -
awk '{print $1}'：提取第一列——即十进制线程 PID -
printf "%x\n"：转成小写十六进制，不带0x前缀，刚好匹配jstack中nid=0x...的后半段 -
grep -A 10 "nid=0x{}"：向后多打 10 行，确保捕获到线程状态（java.lang.Thread.State: RUNNABLE）、堆栈首几层（常含业务方法名）
注意 jstack 输出中 nid 和 os_prio 的实际含义
nid 是 JVM 线程的本地 ID，等于 Linux 下该线程的 LWP ID（即 top -H 显示的 PID），但以十六进制呈现；os_prio 是操作系统调度优先级，和 CPU 占用无直接关系——别被高 os_prio 带偏。真正要盯的是：
- 线程状态是否为
RUNNABLE（非WAITING或TIME_WAITING） - 堆栈顶部是否在执行计算密集型操作（如
String.hashCode()、Arrays.sort()、正则匹配、JSON 序列化循环） - 是否在死循环里反复 new 对象或调用 synchronized 方法（看锁竞争痕迹）
常见误判：看到 WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@... 就以为是锁问题，其实可能是上游线程一直不唤醒它——得往上翻调用链，找到那个始终 RUNNABLE 却没推进逻辑的线程。
为什么不用 pidstat -t？它和 top -H 的线程视角有差异
pidstat -t -p $(pgrep -f 'java.*app.jar') 1 确实也能看线程 CPU，但它默认按线程名（-T）聚合，且部分 JDK 版本下线程名会被截断或显示为 Thread-123，丢失上下文。更重要的是：pidstat 的 TID 列仍是十进制，仍需 printf "%x" 转换，没省事。而 top -H 的实时排序（按 %CPU 降序）更直观，配合 head -1 可稳定抓最高点——这点在突发毛刺场景下很关键。
另外提醒：top -H 显示的 PID 是瞬时快照值，如果线程生命周期短（比如刚创建就结束），可能错过。此时应改用 perf record -e cycles -p $(pgrep -f java) -g -- sleep 5 捕获热点函数，再用 perf script | flamegraph.pl 生成火焰图——那是另一个维度的排查了。
