在Java里如何防止线程死锁问题_Java死锁产生原因与解决思路_技术教程

死锁典型场景是线程间嵌套加锁顺序不一致；应按对象哈希值升序加锁、避免锁内调用外部方法、缩小同步范围；推荐用ReentrantLock.tryLock()超时机制规避；jstack和ThreadMXBean可检测死锁；LockSupport.park/unpark误用亦致逻辑死锁；根本解法是消除共享可变状态。

死锁的典型触发场景：嵌套 synchronized 锁顺序不一致

Java 中最常见死锁，是两个线程分别持有对方需要的锁，又同时申请对方持有的锁。比如 Account 类中 transfer() 方法用 synchronized(this) 锁账户实例，但若线程 A 调用 fromA.transfer(toB)，线程 B 同时调用 fromB.transfer(to

A)，就极易因锁获取顺序不一致陷入死锁。

关键点不是“用了 synchronized”，而是多个锁之间缺乏全局一致的获取顺序。

永远按对象哈希值（或 ID）升序加锁：

if (System.identityHashCode(from) < System.identityHashCode(to)) {
    synchronized (from) {
        synchronized (to) { /* transfer */ }
    }
} else {
    synchronized (to) {
        synchronized (from) { /* transfer */ }
    }
}

避免在持有锁时调用外部方法（尤其是可能获取其他锁的第三方代码）
不要用 synchronized 修饰整个方法体，而应缩小同步块范围，只锁真正共享的临界区

使用 tryLock() 主动规避死锁

ReentrantLock.tryLock(long, TimeUnit) 是比内置锁更可控的选择——它允许超时放弃，从而打破死锁循环。

适用场景：你无法控制锁获取顺序，但能接受「重试」或「失败降级」；例如分布式 ID 生成器、缓存预热任务等对实时性要求不高但需高可用的逻辑。

必须配合 lockInterruptibly() 或 tryLock() 使用，不能混用 synchronized 和 ReentrantLock 保护同一资源
每次 tryLock() 成功后，务必在 finally 块中 unlock()，否则会永久泄漏锁
超时时间不宜过短（如 10ms），否则可能因 GC 暂停误判为锁争用；建议从 100ms 起步，结合压测调整

检测与诊断：jstack + 线程 dump 分析

运行时发现程序卡住、响应变慢，第一反应不是改代码，而是抓现场：jstack -l 输出中搜索 deadlock 或观察多个线程状态为 BLOCKED 且都在等待同一个 java.lang.Thread.State: BLOCKED (on object monitor)。

注意：jstack 只能发现已发生的死锁，不能预测；且 JDK 8+ 的 -l 参数才显示锁信息（包括 Owns Monitor 和 Waiting to Monitor）。

生产环境别等出问题再执行 jstack，应配置 JVM 参数 -XX:+PrintGCDetails -XX:+PrintGCDateStamps 并定期采集线程快照
避免在高峰期频繁执行 jstack，它会触发全局 safepoint，可能导致 STW 延迟
用 ThreadMXBean.findDeadlockedThreads() 可编程检测，适合嵌入健康检查端点