Java并发编程中的线程死锁分析与解决方法_技术教程

死锁典型模式是多线程以不同顺序获取同一组锁，满足互斥、占有并等待、不可剥夺、循环等待四条件；jstack -l可定位，统一加锁顺序、tryLock超时、缩小同步范围是三大预防策略。

死锁发生的典型代码模式

Java中死锁最常出现在多个线程以不同顺序获取同一组Object锁（或synchronized块）时。比如线程A先锁resourceA再尝试获取resourceB，而线程B恰好相反——这种交错加锁就是死锁温床。

常见误用场景包括：银行转账（账户A→B 和 B→A 同时发起）、数据库连接池中连接与事务锁耦合、自定义资源管理器未统一加锁顺序。

只要两个及以上线程互相持有对方需要的锁，且都不释放，就满足死锁的四个必要条件（互斥、占有并等待、不可剥夺、循环等待）
synchronized方法、synchronized(this)、synchronized(obj) 都可能参与死锁；ReentrantLock 同样适用，只是多了tryLock()等破局手段
JVM不会主动检测或中断死锁线程，除非你显式调用ThreadMXBean.findDeadlockedThreads()

如何用jstack定位死锁线程

运行中的Java进程若疑似卡死，优先用jstack抓取线程快照——它能直接标出Found one Java-level deadlock:并列出所有卷入线程的堆栈和锁状态。

执行命令：jstack -l > thread_dump.txt，其中-l参数启用锁信息输出，否则看不到locked 细节。

关键识别点：

看输出中是否出现java.lang.Thread.State: BLOCKED (on object monitor) + waiting to lock
对比多个线程的locked 和waiting to lock 地址，形成闭环即为死锁
注意：parking to wait for 属于Unsafe.par k()，不等于synchronized阻塞，别误判

避免死锁的三种实操策略

预防优于诊断。真实项目里，靠jstack救火成本太高，应在编码阶段切断死锁路径。

统一加锁顺序：给所有可竞争资源定义全局唯一序号，要求线程始终按序号升序（或降序）获取锁。例如转账时规定：总是先锁Math.min(accountA.id, accountB.id)对应账户。

使用带超时的锁获取：改用ReentrantLock.tryLock(long timeout, TimeUnit unit)。失败后释放已持锁并重试/回退，打破“占有并等待”条件。

缩小同步范围 + 减少锁数量：避免在synchronized块内做I/O、远程调用或长耗时计算；考虑用ConcurrentHashMap代替Hashtable，用AtomicInteger代替synchronized计数。

示例：用tryLock避免转账死锁

public boolean transfer(Account from, Account to, BigDecimal amount) {
    ReentrantLock firstLock = from.getLock();
    ReentrantLock secondLock = to.getLock();
    // 按hashcode强制顺序，避免依赖业务ID
    if (firstLock == secondLock) return false;
    if (firstLock.hashCode() > secondLock.hashCode()) {
        ReentrantLock temp = firstLock;
        firstLock = secondLock;
        secondLock = temp;
    }
    if (firstLock.tryLock()) {
        try {
            if (secondLock.tryLock(100, TimeUnit.MILLISECONDS)) {
                try {
                    // 执行转账逻辑
                    return true;
                } finally {
                    secondLock.unlock();
                }
            }
        } finally {
            firstLock.unlock();
        }
    }
    return false;
}