死锁是并发逻辑缺陷的必然结果，需同时满足互斥、持有并等待、不可剥夺、循环等待四条件；jstack可快速定位，jconsole/visualvm提供图形化分析，threadmxbean支持程序内主动监控预警。
死锁不是偶发异常，而是并发逻辑缺陷的必然结果。只要四个条件同时满足——互斥、持有并等待、不可剥夺、循环等待——死锁就一定会发生。排查的关键不在于“有没有”，而在于“在哪一层、哪几行代码里形成了等待闭环”。
死锁是怎么悄悄发生的
最典型的场景是两个线程交叉获取两把锁：线程A先锁住资源1再等资源2，线程B却先锁住资源2再等资源1。双方都不愿释放已持锁，也不愿超时退出，于是彻底僵住。这种模式在数据库事务、缓存更新、服务间调用链中极易复现，比如转账操作中账户A→B和B→A的加锁顺序不统一。
其他隐蔽成因包括：
- 嵌套调用中隐式加锁（如某个工具方法内部又调用了另一个加锁方法）
- 使用不同对象实例作锁但语义相同（如 new Object() 多次创建，误以为是同一把锁）
- 锁粒度不合理，一段长流程全包在一个 synchronized 块里，放大冲突概率
jstack 是定位死锁的第一响应工具
它轻量、无侵入、JDK自带，生产环境首选。操作三步到位：
- 用 jps -l 找出目标Java进程ID（例如 8924）
- 执行 jstack 8924 > dump.txt 导出线程快照
- 打开 dump.txt，直接搜索关键词 “Found one Java-level deadlock”
命中后会清晰列出谁持有什么锁、正在等什么锁，例如：
"Thread-1": waiting to lock monitor 0x00007f8c8c0b5d60 (object 0x00000007d5a3a0a0, a java.lang.Object), which is held by "Thread-0"
"Thread-0": waiting to lock monitor 0x00007f8c8c0b8d60 (object 0x00000007d5a3a0d0, a java.lang.Object), which is held by "Thread-1"
这两行就是死锁证据链，对应代码中的 synchronized 块位置也能从后续堆栈里快速定位。
图形化工具让分析更直观
当线程数多、调用链深时，纯文本容易看花眼。JConsole 和 VisualVM 提供一键检测能力：
- JConsole：连接进程后点“线程”页签 → “检测死锁”按钮 → 自动高亮死锁线程并展示锁依赖图
- VisualVM（需装 Threads Inspector 插件）：可按状态筛选线程，“Deadlocked”状态一目了然，双击即跳转到具体锁对象和源码行号
它们的优势在于把抽象的“等待关系”转化成可视化节点与连线，适合团队协作排查或向非开发同事说明问题。
程序内主动监控更防患于未然
靠人工触发 jstack 毕竟滞后。可在关键服务启动时集成 ThreadMXBean 实时巡检：
- 定时调用 ManagementFactory.getThreadMXBean().findDeadlockedThreads()
- 返回非 null 数组即表示当前存在死锁，可立即记录告警、触发 dump 或熔断降级
- 配合 Prometheus + Grafana，还能把“死锁发生次数/小时”做成可观测指标
这不是替代排查，而是把被动救火变成主动预警，尤其适合高可用要求严苛的中间件或网关服务。
