Thread Dump是定位CPU瓶颈最直接有效的手段，通过jstack -l连续抓取多次快照，可精准识别RUNNABLE热点线程、BLOCKED锁争用及死锁，结合锁地址交叉验证即可闭环定位问题根因。
CPU瓶颈定位中，生成并分析 Thread Dump 是最直接有效的手段之一。它不依赖监控图表的“猜测”，而是拿到 JVM 内部线程的真实快照，帮你看到哪些线程在疯狂执行（RUNNABLE）、哪些在互相等待（BLOCKED/死锁）、哪些卡在 I/O 或锁上（WAITING/TIMED_WAITING）。
一、快速生成高质量 Thread Dump（关键在时机和参数）
问题刚出现时抓取才有效——等 CPU 回落再 dump，就只剩“太平盛世”了。
-
Linux/Unix 环境首选 jstack -l：-l 参数会输出显式锁（synchronized 和 java.util.concurrent.Lock）持有与等待详情，死锁分析离不开它。
命令示例：jstack -l $(pgrep -f 'MyApp.jar') > /tmp/threaddump_$(date +%s).txt - 连续抓 2–3 次，间隔 5 秒：单次 dump 只是瞬态，多次对比才能看出“持续 RUNNABLE”的热点线程，或“始终 BLOCKED”的锁争用点。
-
替代方案（无 jstack 时）：向 Java 进程发
kill -3 <pid>，JVM 会将 dump 输出到 stdout 或 catalina.out（Tomcat）、nohup.out 等日志文件中；注意确认应用日志重定向配置，避免丢数据。
二、聚焦三类关键线索，跳过无关堆栈
一份典型 dump 有几百行，别从头读。按目标直奔重点：
-
找高 CPU 线程（耗时操作）：先用
top -H -p <pid>找出占用 CPU 最高的线程 tid（十进制），转成十六进制（如 12345 → 0x3039），然后在 dump 中搜索0x3039。定位到该线程后，看它的堆栈是否长期停留在某个计算方法、正则匹配、JSON 序列化或空循环里。 -
找死锁线程（jstack 自带检测）：dump 文件末尾通常有专门区块，标题为
Found one Java-level deadlock:。如果有，直接看它列出的线程名、锁对象地址和相互等待关系——这是最明确的死锁证据。 -
找批量阻塞线程（锁争用）：搜索
java.lang.Thread.State: BLOCKED，统计数量。若几十个线程都 BLOCKED 在同一行代码（比如at com.example.Service.updateOrder(...)），且都在等同一个锁（看waiting to lock <0x...>地址是否一致），说明这里存在严重串行化瓶颈。
三、结合锁信息判断问题类型
仅看线程状态不够，必须对照锁字段交叉验证：
立即学习“Java免费学习笔记（深入）”；
- 一个线程显示
State: BLOCKED (on object monitor)，同时有- waiting to lock <0x0000000712345678>—— 它在等某个 synchronized 锁。 - 另一线程显示
locked <0x0000000712345678>，且状态是 RUNNABLE —— 它持有了那个锁，但可能执行缓慢（比如在处理大文件或慢 SQL），导致别人一直等。 - 若两个线程互相
waiting to lock对方已locked的不同对象（如 A 等 B，B 等 A），就是标准死锁，无需怀疑。
四、辅助验证与避坑提醒
分析结论要能闭环验证，避免误判：
- 别只信一次 dump：RUNNABLE 线程可能是瞬间状态；连续 3 次 dump 都显示同一线程在执行同一段代码，才可判定为热点。
-
区分“真死锁”和“假等待”：数据库连接池耗尽时，线程常卡在
getConnection()的 WAITING 状态，这不是 JVM 层死锁，需查 DB 连接数和慢查询。 -
注意线程命名规范：自定义线程名（如
pool-order-processor-3）比默认的Thread-123更易关联业务逻辑，建议在创建线程池时统一设置。
