java死锁是四大必要条件同时成立的必然结果，即互斥、持有并等待、不可剥夺和循环等待；jstack -l是最直接无需改代码的诊断工具，可精准定位死锁线程及锁依赖关系。
Java 中死锁不是偶然现象，而是四个条件同时成立时的必然结果；jstack 是最直接、无需改代码就能确认死锁存在的诊断工具。
死锁发生的四大必要条件
这四个条件缺一不可，只要打破任意一个，死锁就不会发生：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 互斥条件：资源（如 synchronized 锁对象或 ReentrantLock）一次只能被一个线程持有，其他线程无法并发访问。
- 持有并等待（请求与保持）：线程已获取至少一个锁，同时又去申请另一个锁，且不释放已持有的锁。例如：先 synchronized(lockA)，中间调用可能加锁的方法，再 synchronized(lockB)。
- 不可剥夺条件：Java 中锁不能被强制中断或抢走。synchronized 没有超时机制；ReentrantLock.lock() 也无法由其他线程解除——除非调用 unlock() 或使用 tryLock(timeout) 主动放弃。
- 循环等待条件：多个线程形成闭环依赖，比如线程 A 等待线程 B 持有的锁，线程 B 又等待线程 A 持有的锁。这是最常见也最容易修复的一环，统一加锁顺序即可破除。
jstack 排查死锁的实操步骤
只要 JVM 进程还在运行，jstack 就能抓取真实线程状态，不需要提前配置参数或重启应用。
- 获取进程 PID：执行 jps -l，找到你的主类对应数字 ID（如 12345）。Docker 容器内需进入容器或用 docker top 配合 ps 查找。
- 生成带锁信息的快照：务必加上 -l 参数，执行 jstack -l 12345 > deadlock.log。不加 -l 就看不到谁持有什么锁、在等什么锁。
-
定位死锁摘要：打开日志文件，直接翻到末尾，查找 "Found one Java-level deadlock" 区块。它会清晰列出：
- 参与死锁的线程名（如 "Thread-0"、"Thread-1"）
- 每个线程当前 locked 的锁地址
- 每个线程正在 waiting to lock 的锁地址
- 阻塞发生在哪一行源码（如 DeadLockTest.java:17）
-
对照代码验证冲突点：根据栈信息回看源码，重点检查两个线程的加锁顺序是否相反。例如：
- Thread-0 在第17行先锁 lockA，再试图锁 lockB
- Thread-1 在第32行先锁 lockB，再试图锁 lockA
排查时容易忽略的关键细节
jstack 输出看似简单，但几个细节常导致误判：
- 没发现 "Found one Java-level deadlock" 不代表没死锁——可能是瞬时状态，建议连续执行 2–3 次 jstack -l 对比；也可能是活锁、自旋或 native 层阻塞，jstack 看不到。
- 看到大量线程状态为 BLOCKED (on object monitor) 但没标死锁，要人工比对 locked 和 waiting to lock 地址是否交叉成环。
- JDK 版本影响输出格式：JDK 11+ 明确区分 WAITING (on object monitor)（synchronized）和 WAITING (parking)（LockSupport），别混淆锁类型。
- 线上环境权限不足会导致 "Unable to open socket file"，应切换为启动应用的同一用户执行 jstack。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
