ThreadMXBean 只能检测 monitor 锁死锁，返回死锁线程 ID 数组；对 ReentrantLock 默认无效，需显式开启公平模式并手动遍历；jstack 的“Found N deadlock.”是确定性结论，需核对 waiting to lock 与 locked 的地址一致性。
死锁发生时 ThreadMXBean 能查到什么
Java 自带的 ThreadMXBean 是唯一能在运行时无侵入检测死锁的官方机制。它不预测、不拦截，只在死锁已形成后扫描所有线程的锁持有/等待关系，返回一个 long[] 数组——里面是死锁线程的 threadId。
关键点在于：它只能发现「互相持有对方所需 monitor 锁」的循环等待，对 ReentrantLock 默认不生效（除非显式开启公平模式并配合 getOwner() 等手动遍历）。
-
ThreadMXBean.findDeadlockedThreads()返回null表示未检测到死锁；返回空数组表示有死锁但未包含同步器（如ReentrantLock） - 必须通过
ManagementFactory.getThreadMXBean()获取实例，且 JVM 需启用监控（默认开启） - 该方法会触发一次全局线程状态快照，高并发下有轻微性能抖动，不宜高频轮询
ThreadMXBean bean = ManagementFactory.getThreadMXBean();
long[] deadlockedIds = bean.findDeadlockedThreads(); // 注意：仅限 monitor 锁
if (deadlockedIds != null && deadlockedIds.length > 0) {
for (long id : deadlockedIds) {
ThreadInfo info = bean.getThreadInfo(id, Integer.MAX_VALUE);
System.out.println("Deadlocked thread: " + info.getThreadName());
}
}
用 jstack 定位死锁现场的真实输出特征
jstack 是线上最可靠的死锁诊断命令，它的输出里「Found 1 deadlock.」段落不是提示，而是结论性证据——只要出现，就代表 JVM 已确认死锁成立。
真实输出中重点关注三类信息：线程名、waiting to lock 后的十六进制地址、以及同一地址出现在另一处的 locked 行。这两个地址一致，才构成闭环。
- 不要只看「
java.lang.Thread.State: BLOCKED」——大量阻塞不等于死锁，必须存在互相等待的锁地址链 -
jstack -l会额外打印AbstractOwnableSynchronizer信息，对ReentrantLock死锁有效 - 如果
jstack输出里没有「Found N deadlock.」但有多处parking to wait for，可能是LockSupport.park()引发的活锁或资源饥饿，不是死锁
synchronized 嵌套顺序不一致为何必然导致死锁风险
死锁四必要条件中，“循环等待”在 Java 里最常由嵌套 synchronized 的加锁顺序不一致触发。这不是概率问题，而是逻辑必然：只要两个线程以不同顺序申请同一组对象锁，且都未释放前就申请下一个，就满足死锁全部条件。
- 典型错误模式：
threadA synchronized(obj1) → synchronized(obj2)，而threadB synchronized(obj2) → synchronized(obj1) - 即使 obj1 和 obj2 是不同类的实例，只要被多个线程交叉访问，风险就存在
- 加锁顺序无法靠“先判断再加锁”规避——因为判断本身也需要同步，否则判断结果可能过期
// 危险：顺序依赖调用方，无法保证全局一致
void transfer(Account from, Account to, int amount) {
synchronized(from) {
synchronized(to) { // ← 顺序由参数决定，不可控
from.withdraw(amount);
to.deposit(amount);
}
}
}
用 tryLock() 主动打破死锁循环的实操要点
ReentrantLock.tryLock(long, TimeUnit) 是少数能从代码层面主动防御死锁的手段。它不强制阻塞，超时即放弃，从而切断循环等待链条。但这不是万能解药，使用时必须处理好业务语义回退。
- 必须指定超时时间（如
100, TimeUnit.MILLISECONDS），设为0等价于非阻塞尝试，设为-1或不带参的tryLock()仍是阻塞行为 - 获取锁失败后不能简单重试——重试可能再次进入相同竞争路径；应记录日志、降级处理或抛出特定异常供上层决策
- 若涉及多把锁，需按固定顺序申请，并在任意一把失败时释放已持有的锁（注意 try-finally 保证）
ReentrantLock lock1 = new ReentrantLock();
ReentrantLock lock2 = new ReentrantLock();
boolean transfer(Account from, Account to, int amount) throws InterruptedException {
if (!lock1.tryLock(100, TimeUnit.MILLISECONDS)) return false;
try {
if (!lock2.tryLock(100, TimeUnit.MILLISECONDS)) return false;
try {
from.withdraw(amount);
to.deposit(amount);
return true;
} finally {
lock2.unlock();
}
} finally {
lock1.unlock();
}
}
死锁不是偶发异常，而是设计缺陷的确定性暴露。真正难防的不是 monitor 锁冲突，而是混合使用 synchronized、ReentrantLock、StampedLock 甚至 wait()/notify() 时，锁边界和所有权转移变得模糊——这时连 jstack 都可能只显示部分线索。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
