Java并发编程中的死锁检测与防范技术

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 行。这两个地址一致，才构成闭环。

Kive

一站式AI图像生成和管理平台

下载

立即学习“Java免费学习笔记（深入）”；

• 不要只看「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();
    }
}