jstack定位死锁步骤详解

用jstack -l 可快速识别死锁，它会显式输出“Found 1 deadlock”区块并列出持锁与待锁地址；若显示“no deadlocks”但程序卡住，可能是BLOCKED、I/O阻塞、JUC非公平锁或Native层死锁。

怎么用 jstack 快速识别死锁线程

直接运行 jstack -l ，其中 是 Java 进程 ID。加上 -l 参数是关键——它会触发 JVM 检测死锁并显式输出 Found 1 deadlock. 区块，里面包含所有卷入死锁的线程、各自持有的锁和正在等待的锁。

常见错误是只用 jstack （不带 -l），此时 jstack 只 dump 全量栈，但不会做死锁分析，你需要手动翻找 WAITING 状态线程 + java.util.concurrent.locks 或 synchronized 锁信息，效率极低且容易漏判。

如何定位到具体哪两行代码在互相等待

死锁区块里每个线程段都会列出完整栈帧，重点看最顶部的几行（即执行位置）和 locked <0x...> / waiting to lock <0x...> 行：

• locked <0x0000000712345678> 表示该线程当前持有这个对象监视器（monitor）
• waiting to lock <0x0000000787654321> 表示它正阻塞在这里，试图获取另一个锁
• 两个线程的 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  > jstack_$(date +%s).log 2>&1

连续执行几次，再比对栈中重复出现的阻塞点。注意不要高频采集（如每秒一次），避免干扰 JVM 正常运行。

真正难的不是看到 “Found 1 deadlock”，而是确认那两个锁是否本不该被同一线程按不同顺序获取——这需要你清楚整个调用链路里锁的粒度和获取顺序，光靠 jstack 给不出修复方案。