jstack -l 是检测 Java 层死锁最轻量手段，可识别 synchronized 和 ReentrantLock 的循环等待，需检查 locked/waiting to lock 地址交叉匹配，且线程须处于 BLOCKED 或 WAITING 状态。

死锁检测的关键在于识别线程之间对对象监视器（Monitor）的交叉等待关系。jstack 是最轻量、最直接的手段，但它只对 Java 层的 synchronized 和 java.util.concurrent.locks.Lock 有效，不涉及 JNI、文件锁或数据库连接等外部资源。

必须用 -l 参数才能准确定位锁归属

jstack 默认输出不显示 ReentrantLock 的持有者和等待者信息，容易漏判。加 -l 后，每个锁会明确标注：

• locked ：该线程正持有这个监视器地址的锁
• waiting to lock ：该线程正阻塞等待这个地址的锁
• 若出现 A 等待 B 持有的锁，B 又等待 A 持有的锁，地址交叉匹配，即构成循环等待

死锁提示只出现在日志末尾，且仅当 JVM 真正捕获到闭环

“Found 1 deadlock” 这类提示不会穿插在中间，固定位于 jstack 输出的最后几行。但要注意：

Expanso yaml-to-json

使用 Expanso Edge 管道将 YAML 输入转换为 JSON 格式。

下载

• 没有提示 ≠ 没有死锁：可能是锁类型不被支持（如自定义非阻塞同步），或线程状态不是 BLOCKED/WAITING（比如已进入 native 调用）
• 线程必须处于 BLOCKED（等待 monitor entry）或 WAITING（parking on condition）状态，才可能被 JVM 判定为参与死锁
• 单纯 sleep、RUNNABLE 或 TIMED_WAITING 不触发死锁检测逻辑

重定向 + grep 是高效筛查的标配操作

生产环境线程数多，控制台输出易截断。推荐流程：

• 执行 jstack -l > thread.log 保存完整快照
• 用 grep -A 10 -B 5 "waiting to lock\|locked" thread.log 快速提取关键锁段
• 比对地址是否成对出现：例如线程 T1 locked 且 waiting to lock ，而线程 T2 正好相反

确认目标进程状态再排查

jstack 对象必须是活跃的 Java 进程：

• 用 ps aux | grep java 核对 PID 是否存在，排除僵尸（zombie）或已挂起进程
• 避免在 GC 压力极大时 dump（如频繁 Full GC），虽不影响检测逻辑，但可能掩盖真实线程行为
• -XX:+UseParallelGC 等 GC 参数对死锁检测无影响，无需调整 JVM 启动参数来辅助排查