用jstack -l 可快速识别死锁，它会显式输出“Found 1 deadlock”区块并列出持锁与待锁地址；若显示“no deadlocks”但程序卡住，可能是BLOCKED、I/O阻塞、JUC非公平锁或Native层死锁。
怎么用 jstack 快速识别死锁线程
直接运行 jstack -l ，其中 -l 参数是关键——它会触发 JVM 检测死锁并显式输出 Found 1 deadlock. 区块，里面包含所有卷入死锁的线程、各自持有的锁和正在等待的锁。
常见错误是只用 jstack （不带 -l），此时 jstack 只 dump 全量栈，但不会做死锁分析，你需要手动翻找 WAITING 状态线程 + java.util.concurrent.locks 或 synchronized 锁信息，效率极低且容易漏判。
如何定位到具体哪两行代码在互相等待
死锁区块里每个线程段都会列出完整栈帧，重点看最顶部的几行（即执行位置）和 locked / waiting to lock 行：
-
locked表示该线程当前持有这个对象监视器（monitor） -
waiting to lock表示它正阻塞在这里，试图获取另一个锁 - 两个线程的
locked和waiting to lock地址交叉出现，就是死锁证据
例如：线程 A 持有 0x123 等待 0x456，线程 B 持有 0x456 等待 0x123 —— 这时立刻查源码中对应类的那两行 synchronized 块或 ReentrantLock.lock() 调用位置。
为什么有时 jstack 显示 “no deadlocks” 却程序卡住
死锁只是卡顿的一种原因，jstack -l 报 “no deadlocks” 并不等于没阻塞问题。可能情况包括：
- 线程处于
BLOCKED（竞争锁失败，但未形成循环等待） - 线程在 I/O（如 socket read、文件读写）上长时间阻塞，状态为
WAITING或TIMED_WAITING，但没锁参与 - 使用了
java.util.concurrent中的非公平锁、自旋锁或StampedLock，jstack 无法解析其内部状态 - Native 层死锁（如 JNI 调用中持锁进入 C 代码再回调 Java），jstack 完全不可见
此时需结合 jstack 全量输出，筛选出长时间停留在某一行的线程，再结合业务逻辑判断是否正常阻塞。
抓取时机和权限注意事项
jstack 必须由与目标 Java 进程相同用户运行，否则会报错 Unable to open socket file；容器环境下更常见——若容器以非 root 用户启动 JVM，宿主机上用 root 执行 jstack 会失败。
另外，jstack 是“快照”操作，如果死锁是瞬时的（比如秒级自动超时释放），可能刚好错过。建议配合监控脚本循环抓取：
jstack -l <pid> > jstack_$(date +%s).log 2>&1</pid>
连续执行几次，再比对栈中重复出现的阻塞点。注意不要高频采集（如每秒一次），避免干扰 JVM 正常运行。
真正难的不是看到 “Found 1 deadlock”，而是确认那两个锁是否本不该被同一线程按不同顺序获取——这需要你清楚整个调用链路里锁的粒度和获取顺序，光靠 jstack 给不出修复方案。
