死锁发生的四个必要条件是互斥、占有并等待、不可剥夺、循环等待：互斥指资源不能被多个线程同时访问；占有并等待指线程持有锁又申请其他锁；不可剥夺指锁不能被强制释放；循环等待指多个线程形成闭环等待链。
死锁发生的四个必要条件是什么
Java 中的死锁不是“随机发生”的异常，而是必须同时满足四个经典条件才会出现：互斥、占有并等待、不可剥夺、循环等待。只要其中任一条件被打破，死锁就不会发生。
在 Java 多线程场景下， synchronized 或 ReentrantLock 造成资源互斥；线程已持有锁又去请求别的锁，就构成“占有并等待”；Java 锁默认不可剥夺（不能由 JVM 强制释放）；而多个线程 A→B、B→A 地交叉请求锁，就形成循环等待链。
- 互斥：比如
synchronized(obj1)和synchronized(obj2)分别保护不同临界区，两者不能同时进入 - 占有并等待：线程 T1 持有
obj1的锁，同时调用synchronized(obj2) - 不可剥夺：T1 不主动释放
obj1，其他线程无法强行获取 - 循环等待：T1 等 T2 释放
obj2，T2 又等 T1 释放obj1
典型代码复现死锁的写法
下面这段代码是教科书级的双线程双锁死锁示例，运行后大概率卡住，且 jstack 能清晰看到 BLOCKED 和循环等待关系：
public class DeadlockExample {
private static final Object lock1 = new Object();
private static final Object lock2 = new Object();
<pre class='brush:java;toolbar:false;'>public static void main(String[] args) {
Thread t1 = new Thread(() -> {
synchronized (lock1) {
System.out.println("T1: acquired lock1");
try { Thread.sleep(100); } catch (InterruptedException e) {}
synchronized (lock2) {
System.out.println("T1: acquired lock2");
}
}
});
Thread t2 = new Thread(() -> {
synchronized (lock2) {
System.out.println("T2: acquired lock2");
try { Thread.sleep(100); } catch (InterruptedException e) {}
synchronized (lock1) {
System.out.println("T2: acquired lock1");
}
}
});
t1.start(); t2.start();
}}
立即学习“Java免费学习笔记（深入）”；
关键点在于：两个线程以**相反顺序**获取同一组锁。哪怕只差几毫秒的时序，就可能让双方各持一锁、互相等待。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
为什么 tryLock(timeout) 能避免死锁
ReentrantLock.tryLock(long, TimeUnit) 提供超时机制，本质是把“无限期等待”变成“有限尝试”，从而破坏“占有并等待”或“循环等待”的持续性。
- 它不会阻塞线程，超时返回
false，线程可选择释放已有锁、重试或退出 - 配合固定加锁顺序（如按对象哈希值排序），能从设计上消除循环等待可能
- 注意：仅用
tryLock()不带参数（非公平立即尝试）并不能防死锁，仍可能陷入循环等待
常见规避模式是“先申请所有锁，失败则全部释放再重来”，但要注意释放顺序与申请顺序无关，只要确保不嵌套等待即可。
排查死锁最有效的手段是什么
不要靠日志猜，Java 自带工具足够直接： jstack -l <pid></pid> 是首选。它会明确标出 Found 1 deadlock. ，并列出每个死锁线程的栈帧、持有的锁和正在等待的锁。
输出中重点关注：
- 线程状态是否为
BLOCKED（而不是WAITING或TIMED_WAITING） - 每行
- waiting to lock和- locked是否形成闭环 - 锁地址（如
0x000000076b5a8a00）是否在多个线程间重复出现
IDEA 或 JConsole 也能图形化展示，但底层都依赖 jstack 数据。线上环境务必保留 -XX:+PrintConcurrentLocks 或定期采集 thread dump。
真正难的不是发现死锁，而是确认哪个业务路径触发了锁顺序错乱——这往往藏在嵌套调用、异步回调或代理增强里。
