如何在Java中检测和避免死锁_并发编程实战技巧

死锁的典型现象是Java程序卡住、线程长时间处于BLOCKED或WAITING状态且CPU使用率极低;快速检测方法包括jstack -l查看Found 1 deadlock、JVM启动加-XX:+PrintConcurrentLocks、JConsole检测死锁;预防手段有tryLock()超时获取、按System.identityHashCode固定顺序加锁、优先使用ConcurrentHashMap等并发工具类替代手动锁。

死锁的典型现象和快速检测方法

Java 程序卡住不动、线程长时间处于 BLOCKEDWAITING 状态,且 CPU 使用率极低,大概率是死锁。JDK 自带工具比写代码更早发现问题:

  • jstack -l 查看线程栈,输出中出现 Found 1 deadlock. 就确认了
  • 在 JVM 启动时加 -XX:+PrintConcurrentLocks,可让 Ctrl+\(Linux/macOS)或 Ctrl+Break(Windows)触发时额外打印锁持有关系
  • JConsole 连上进程后,切换到「线程」页签,点「检测死锁」按钮——它本质调的是 ThreadMXBean.findDeadlockedThreads()

用 tryLock() 主动规避嵌套锁竞争

synchronizedReentrantLock.lock() 是阻塞式获取,一旦顺序不一致就容易形成环路;而 tryLock() 允许设定超时或立即失败,把“等锁”变成“抢锁 + 重试/回退”逻辑:

ReentrantLock lockA = new ReentrantLock();
ReentrantLock lockB = new ReentrantLock();

void transfer(Account from, Account to, BigDecimal amount) {
    while (true) {
        if (lockA.tryLock()) {
            try {
                if (lockB.tryLock(100, TimeUnit.MILLISECONDS)) {
                    try {
                        // 执行转账
                        return;
                    } finally {
                        lockB.unlock();
                    }
                }
            } finally {
                lockA.unlock();
            }
        }
        // 避免忙等,短暂让出 CPU
        Thread.sleep(10);
    }
}

注意:tryLock(long, TimeUnit) 可能抛 InterruptedException,必须处理;永远不要在未获得锁时调用 unlock(),否则会抛 IllegalMonitorStateException

按固定顺序加锁是最简单有效的预防手段

只要所有线程以相同顺序申请锁,环路就无法形成。关键不是“谁先谁后”,而是“全局一致”。常见做法是基于对象身份做排序:

  • System.identityHashCode(obj) 获取稳定哈希值(不依赖 hashCode() 重写)
  • 对多个锁对象排序后依次 lock(),释放时逆序 unlock()
  • 避免在锁内再调用外部方法(尤其是可能获取其他锁的回调),否则顺序控制失效

示例中若两个 Account 实例要加锁,统一按 identityHashCode 升序获取:

private void lockInOrder(ReentrantLock first, ReentrantLock second) {
    int h1 = System.identityHashCode(first);
    int h2 = System.identityHashCode(second);
    if (h1 < h2) {
        first.lock(); second.lock();
    } else if (h1 > h2) {
        second.lock(); first.lock();
    } else {
        // 相同实例,只

锁一次(注意:identityHashCode 理论上可能碰撞,但概率极低) first.lock(); } }

使用 java.util.concurrent 工具类替代手写锁逻辑

很多死锁源于对锁粒度、持有时间、协作机制理解偏差。优先用高阶并发结构:

  • ConcurrentHashMap 替代 HashMap + synchronized —— 它内部分段锁/ CAS,无须手动加锁
  • AtomicInteger / AtomicReference 替代 synchronized 计数或状态更新
  • StampedLock 的乐观读模式适合读多写少场景,避免读线程互相阻塞
  • 需要等待条件时,用 Condition 配合 await()/signal(),而不是自己用 wait()/notify() 混搭 synchronized

这些类本身已规避了常见死锁路径,且经过 JDK 团队长期压测验证。自己实现锁协调逻辑,出错成本远高于学习 API 的时间成本。

真正难的不是识别死锁,而是在业务逻辑膨胀后仍维持锁顺序的一致性;也不是选不用锁,而是判断哪些共享状态真的需要互斥——多数时候,用不可变对象、线程局部变量(ThreadLocal)或消息传递(如 BlockingQueue),比加锁更干净。