死锁发生的四个必要条件是互斥、占有并等待、不可剥夺、循环等待；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 <pid></pid> 输出，-l 参数才能显示锁的详细持有关系。
立即学习“Java免费学习笔记（深入）”；
- 输出中看到
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锁封装）
synchronized 方法，又共用同一个锁对象——这种耦合很难被单元测试覆盖，只能靠代码审查和锁拓扑图来识别。 
