直接回答：thread dump 三板斧：CPU 飙高——top -H 找到吃 CPU 的线程 PID，转十六进制（printf %x），jstack 输出里搜 nid=0x???? 对号入座，看那线程在执行什么栈（常见：正则回溯、序列化大对象、死循环、GC 线程狂转其实是内存问题）。线程 hang——dump 里按状态统计（RUNNABLE/BLOCKED/WAITING 数量），BLOCKED 集中同一把锁是锁竞争，大量 WAITING 在池化对象（数据库连接池获取）是下游资源耗尽。
展开解析：进阶套路：间隔 3~5 秒连抓 3~5 份 dump 做差分——栈纹丝不动的线程是真 hang（死锁或外部调用无超时），栈在变化的是真忙。死锁：jstack 末尾会直接报告 Found one Java-level deadlock，锁顺序不一致是根因，修复靠统一加锁顺序或 tryLock 超时。几个高频根因指纹：BLOCKED 在 logback 的 Appender 上是同步日志竞争（改异步日志）；大量线程等在 SocketRead 且无超时设置（连接池/HTTP 客户端必须配 connect/read timeout，这是 review 红线）；ForkJoinPool commonPool 被打爆（并行流里做了阻塞调用）；虚拟线程场景注意 jstack 默认不列全部虚拟线程，用 jcmd Thread.dump_to_file 或 JFR。工具链：Arthas 的 thread -n 3 直接列出最忙线程省掉手工转换，async-profiler 做持续采样比快照更可靠。最后：dump 只是快照证据，修复常要回到代码与配置——定位后别忘补监控（锁等待、池水位、超时覆盖率）。
追问方向：WAITING 与 TIMED_WAITING 的排查意义差别？本地方法栈怎么看？
（约 490 字）