top -H 不能直接定位 Java 死循环线程，需结合 top -H 查高 CPU 线程、TID 转十六进制、jstack 匹配 nid 并分析栈帧，或用 async-profiler 生成火焰图精准定位热点方法。
在 Linux 中，top 命令本身不支持直接通过 -H 选项查看“各线程的独立资源占比”并精准定位 Java 死循环线程——因为 top -H 显示的是**所有线程（LWP）的 CPU 和内存快照**，但默认不按线程级 CPU 使用率排序，且 Java 线程名在 top 中显示为数字 PID（如 12345），无法直观对应业务逻辑。要准确定位 Java 死循环线程，需结合 top -H + jstack + 线程 ID 十六进制转换，形成闭环分析。
启用线程视图并识别高 CPU 线程
运行以下命令进入线程模式：
top -H -p $(pgrep -f "java.*YourApp")
说明：
-
-H：开启线程（LWP）视角，每行代表一个 OS 线程 -
-p $(pgrep -f "...")：只监控目标 Java 进程的线程，避免被系统线程干扰 - 进入后按 Shift+P 按 CPU% 降序排列，顶部几行即嫌疑线程
- 记下高 CPU 的 TID（Thread ID，即 PID 列），例如
12345
将 TID 转为十六进制并匹配 Java 线程名
Java 线程 dump 中的 nid（native ID）是十六进制表示的 OS 线程 ID。需转换比对：
立即学习“Java免费学习笔记（深入）”；
printf "%x\n" 12345 # 输出：3039
然后用 jstack 抓取当前线程快照：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
jstack <java-pid> > /tmp/threads.log 2>&1
搜索 nid=0x3039（注意前缀 0x），找到对应线程块，例如：
"http-nio-8080-exec-25" #25 daemon prio=5 os_prio=0 tid=0x00007f8a1c0b2000 nid=0x3039 runnable [0x00007f8a0b2e6000]
该线程名为 http-nio-8080-exec-25，状态为 runnable，栈顶若持续在某个循环方法（如 while(true)、compute()、正则匹配等），即高度可疑。
结合线程栈与代码确认死循环逻辑
重点检查匹配线程的栈顶几帧：
- 是否在
java.util.regex.Pattern或String.replaceAll—— 可能遭遇 ReDoS（正则灾难性回溯） - 是否反复调用
HashMap.get/ConcurrentHashMap.computeIfAbsent且 key 构造耗时或存在锁竞争 - 是否在无退出条件的
while(flag)中，且flag未被 volatile 修饰或未被其他线程更新 - 是否在 JNI 调用中阻塞，但
top显示 CPU 高 → 更可能是纯 Java 层无限计算（如空 while 循环、错误的 for 条件）
辅助验证：用 async-profiler 快速采样热点
若环境允许，推荐使用 async-profiler 直接定位热点线程和方法：
./profiler.sh -e cpu -d 30 -f /tmp/flame.html <java-pid>
生成火焰图后，放大 CPU 占比最高的线程分支，可直观看到哪个 Java 方法持续消耗 CPU，无需手动转换 TID，对死循环定位更高效可靠。
