定位Java生产环境CPU飙升需四步：先用top -Hp或ps -mp查高CPU线程TID；再将TID转十六进制得nid；接着用jstack匹配nid找RUNNABLE线程堆栈及可疑代码；最后用async-profiler和jmap交叉验证热点与对象异常。
生产环境 CPU 飙升时，光看 top 或 htop 显示的高 CPU 进程还不够，必须快速定位到具体线程、再映射到 Java 线程栈中的 nid（Native ID），最终关联到可疑代码行。关键在于打通「进程 → 线程 → nid → Java 线程名 → 堆栈 → 变量/循环逻辑」这条链路。
第一步：抓取高 CPU 的 Java 进程和线程 PID
用 top -Hp <pid> 查看该进程下所有线程的 CPU 占用（注意切换为线程视图：按 H），记下 CPU% 最高的几个线程的十进制 TID（即 Linux 线程 ID）。
也可用 ps -mp <pid> -o THREAD,tid,time | sort -k3r 更清晰排序。
第二步：将 TID 转为十六进制 nid（用于 jstack 匹配）
nid 就是线程在 JVM 内部的 native ID，jstack 输出中显示为 nid=0x<hex>，它等于线程 TID 的十六进制表示（小写，无前缀补零）。
例如 TID 是 29832，执行：
printf "%x\n" 29832 → 得到 7488，对应 jstack 中的 nid=0x7488。
第三步：用 jstack 定位线程堆栈与上下文变量
执行 jstack <pid> > jstack.out，然后搜索 nid=0x7488（注意带 0x 前缀）。找到对应线程块后，重点关注：
- 线程状态：RUNNABLE 最可疑（不是 BLOCKED/WAITING）
- 堆栈最顶部几行：是否在反复调用同一方法？比如
String.replaceAll、HashMap.get、或某段 for 循环内嵌正则 - 局部变量或对象字段：是否有未关闭的流、死循环条件变量、缓存 key 拼接错误导致哈希冲突激增？
- 是否在 GC 相关线程（如 GC task thread）里卡住？需结合 jstat 看 GC 频率
第四步：交叉验证——确认是不是变量或逻辑引发的自旋/高频计算
单靠 jstack 可能不够，建议同步做：
- 用 async-profiler 录制热点方法：
./profiler.sh -e cpu -d 30 -f profile.html <pid>，直接看到哪行代码耗 CPU 最多 - 检查该线程正在操作的对象：用 jmap -histo <pid> | head -20 看对象实例数是否异常（如大量 StringBuilder、Pattern、或自定义 DTO）
- 若怀疑是某个缓存 key 或参数触发，从日志中提取该线程处理的请求 traceId / 参数，复现逻辑
整个过程不复杂但容易忽略 TID 和 nid 的进制转换细节，以及 jstack 中线程名和实际业务逻辑的对应关系。真正的问题往往藏在“看起来很短”的一行代码里——比如一个没加边界检查的 while 循环，或一个被反复 compile 的正则表达式。
