Java并发编程中为什么会发生死锁_原因与避免方法_技术教程

死锁发生的四个必要条件是互斥、占有并等待、不可剥夺、循环等待；Java中synchronized和ReentrantLock默认满足前三个，多线程乱序争锁易引发循环等待。

死锁发生的四个必要条件是什么

Java中死锁不是随机出现的，它必须同时满足四个经典条件：互斥、占有并等待、不可剥夺、循环等待。只要其中任一条件不成立，死锁就无法形成。

在 Java 中，synchronized 和 ReentrantLock 默认都是可重入但不可剥夺的；线程一旦获得锁，其他线程只能阻塞等待；而多个线程按不同顺序申请同一组锁，就极易触发循环等待。

synchronized 块嵌套时，若线程 A 持有 lockA 并尝试进入 synchronized(lockB)，同时线程 B 持有 lockB 并尝试进入 synchronized(lockA)，就会卡住
ReentrantLock.tryLock() 可打破“占有并等待”，因为它允许超时或立即失败，是主动规避的关键手段
JVM 不会自动检测或中断这种等待——除非你显式调用 thread.interrupt() 且锁实现支持响应中断（如 lock.lockInterruptibly()）

如何用 jstack 快速定位死锁线程

运行中的 Java 进程若疑似死锁，jstack 是最轻量、最直接的诊断工具。它能明确标出 Found one Java-level deadlock: 并列出互相等待的线程栈。

前提是 JVM 启动时未禁用偏向锁或相关监控（默认开启）。生产环境建议保留 -XX:+PrintGCDetails 和定期采集 jstack -l 输出，-l 参数才能显示锁的详细持有关系。

输出中看到 java.lang.Thread.State: BLOCKED (on object monitor) 且 waiting to lock 与另一个线程的 locked ownable synchronizers 对应，就是典型信号
注意区分“假死锁”：比如某线程长期执行 CPU 密集任务，其他线程只是正常等待，并未形成锁循环
如果应用使用了线程池（如 ThreadPoolExecutor），要检查 corePoolSize 是否过小导致任务排队+锁竞争加剧

避免死锁的三种实操策略

预防比排查更有效。核心思路是破坏死锁四条件之一，尤其聚焦于“循环等待”和“占有并等待”。

public class DeadlockAvoidance {
    private final Object lockA = new Object();
    private final Object lockB = new Object();

    // ✅ 正确：统一加锁顺序（按对象哈希值排序）
    public void transfer(Account from, Account to, BigDecimal amount) {
        Object firstLock = System.identityHashCode(from) < System.identityHashCode(to) ? from : to;
        Object secondLock = (firstLock == from) ? to : from;

        synchronized (firstLock) {
            synchronized (secondLock) {
                from.withdraw(amount);
                to.deposit(amount);
            }
        }
    }
}

始终按全局一致顺序获取多个锁（例如用 System.identityHashCode() 比较，而非业务字段，避免哈希冲突或 null 问题）
用 tryLock(long, TimeUnit) 替代无条件 lock()，获取失败时释放已持锁并重试或降级处理
减少锁粒度：把一个大 synchronized 方法拆成多个小同步块，或改用 ConcurrentHashMap、AtomicInteger 等无锁/分段锁结构

ReentrantLock 与 synchronized 在死锁风险上的差异

语法上 synchronized 更简洁，但 ReentrantLock 提供了更多控制能力来降低死锁概率，代价是必须手动管理锁生命周期。

synchronized 无法尝试获取、无法超时、无法响应中断，一旦阻塞就只能等——这是它在复杂并发
场景中更易诱发死锁的原因
ReentrantLock 的 tryLock()、lockInterruptibly()、公平模式（new ReentrantLock(true)）都能缓解，但要注意公平锁会显著降低吞吐量
两者都存在“锁升级失败仍持有旧锁”的风险：比如先 synchronized(A) 再 lockB.lock()，若后者失败，必须确保 A 被正确释放——这要求严谨的 finally 或 try-with-resources（配合自定义 AutoCloseable 锁封装）