17370845950

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

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

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

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

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

synchronized 和 ReentrantLock.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），比加锁更干净。