识别思路总览
先说几个核心判断。Ja va的线程死锁到底怎么查？本质上是一个“抓证据、看链条、堵源头”的过程。第一步是确认症状——应用无响应或者接口反复超时，CPU占用却很低，线程长时间卡住，十有八九是线程阻塞的典型信号。这时候二话不说，先采集证据，也就是导出一份线程转储（Thread Dump）。最直接的工具是jstack -l ，或者直接在jconsole、VisualVM里连上进程点一下检测死锁。关键的一步：在dump里搜“Found one Ja va-level deadlock:”这个关键字，如果没自动标记出来，那就手动找——大量线程处于BLOCKED状态，且伴随waiting to lock <0x…>与locked <0x…>成对出现，这就构成了环形等待链。
日志中的关键特征
怎么识别？有几个硬指标：
- 死锁自动标记：dump文件开头如果出现“Found one Ja va-level deadlock:”，后面就会列出互相等待的线程、各自持有的锁与等待的锁，直接定位到参与死锁的线程和代码位置。这个标记是最直接的。
- 线程状态与锁线索：重点关注BLOCKED (on object monitor)且出现waiting to lock <0x…>的线程，这就是在等待某个对象监视器；同一线程栈里如果看到locked <0x…>，说明它已经持有了某个锁。另外，waiting for monitor entry表示正在竞争进入synchronized块或方法。需要注意的是，Waiting on condition通常与网络I/O或条件变量有关，不一定是锁竞争。
- 锁地址串联成环：用locked与waiting to lock的对象地址（比如
0x000000076e9a7d78），在dump里交叉搜索。如果能串成“A持有→B等待；B持有→A等待”这种闭环，死锁铁证如山。 - 辅助线索：dump里还会打印线程的tid、nid、栈顶方法、当前状态是否是Runnable/Waiting/Timed_Waiting等，这些细节对判断业务位置和阻塞来源都很有帮助。
快速排查步骤
实际操作起来，分几步走：
- 先用
jps -l或系统命令找到目标Ja va进程的PID。 - 导出线程转储：执行
jstack -l，如果进程挂死了，用> thread_dump.txt jstack -F强制dump。 - 一键识别：在dump文件里搜“deadlock”，或者用jconsole/VisualVM → 线程 → 检测死锁。
- 手工验证环形等待：对每个BLOCKED线程，记录其waiting to lock <地址>，然后搜索该地址的locked <地址>，顺藤摸瓜找到持有者线程，直到形成闭环。
- 连续取证：为了避免偶发竞争，建议每隔5秒取一次dump，连续3–5次，观察锁持有和等待关系是否稳定复现。
- 程序自检：更主动的做法是在代码里通过
ThreadMXBean.findDeadlockedThreads()定期探测死锁线程并打印ThreadInfo，用于线上预警。
常见误判与排查技巧
这里有几个容易踩的坑：
- 区分阻塞与正常等待：BLOCKED状态且出现waiting to lock，才是锁竞争；而WAITING或TIMED_WAITING，以及Waiting on condition，常见于
sleep、join、Object.wait、网络I/O、数据库I/O等场景，不一定是死锁。 - 别只靠一次dump下结论：复杂竞争或调度下，建议多取几次dump对比，或者用JFR（Ja va Flight Recorder）记录锁事件后再分析，这样更稳妥。
- 善用工具：比如Arthas的
thread -b命令，能快速查看阻塞点与锁关系，缩短定位时间，值得一试。
从日志到修复的闭环
找到死锁只是第一步，修复才是关键。根源上，多把锁的获取顺序不一致导致循环等待，是死锁最常见的模式。修复方案也比较成熟：
- 统一加锁顺序：比如按对象哈希值或显式序号排序，彻底破坏循环等待条件。
- 使用ReentrantLock.tryLock()：配合超时回退与重试，避免无限等待。
- 减少嵌套锁、缩小同步范围：必要时用并发容器替代粗粒度的
synchronized。
最后提一句预防：在CI或代码扫描里启用静态分析规则（比如FindBugs或SonarQube的并发规则），并在测试环境中压测复现后再上线，效果远比事后排查好得多。
