用 jstack -l <pid> 可让 JVM 主动检测死锁并标出循环等待关系；仅 jstack <pid> 不触发分析，-l 参数不可省；输出末尾“Found one Java-level deadlock”即确认死锁，否则仅说明无 JVM 级死锁。

直接用 jstack -l <pid> 就能快速定位死锁，关键不是看全量栈，而是让 JVM 主动检测并标出循环等待关系。

用对命令：-l 参数不可省

只运行 jstack <pid> 只会输出所有线程的原始堆栈，不触发死锁分析；加上 -l（小写 L）参数后，JVM 会扫描锁持有与等待关系，并在输出末尾显式标记：

• 出现 “Found one Java-level deadlock” 区块，说明检测到死锁
• 若显示 “No deadlocks found”，不代表没阻塞问题，只是没满足 JVM 级死锁判定条件（比如非 synchronized 锁、native 层锁、I/O 阻塞等）
• 建议将结果重定向保存：jstack -l <pid> > deadlock.log，方便后续逐行查看

看懂死锁区块：锁定交叉等待链

在 “Found one Java-level deadlock” 下方，会列出所有卷入死锁的线程。每个线程段里重点关注两行：

• locked <0x...>：该线程当前持有的锁对象地址
• waiting to lock <0x...>：它正在阻塞等待获取的另一个锁地址

如果线程 A 持有 0x123 等待 0x456，线程 B 持有 0x456 等待 0x123，就构成闭环——这就是死锁证据。对应到代码，就是两个 synchronized 块或 ReentrantLock.lock() 调用位置顺序不一致。

区分真假阻塞：别把 WAITING 当死锁

不是所有 “卡住” 都是死锁。需结合线程状态和上下文判断：

• BLOCKED (on object monitor)：真正在争抢 synchronized 锁失败，可能参与死锁
• WAITING (parking) 或 TIMED_WAITING：常见于 await、join、LockSupport.park、队列 take/poll 等，属于正常等待，不涉及锁竞争
• 状态为 RUNNABLE 但 CPU 持续飙高，大概率是无限循环或密集计算，不是死锁

死锁之外的卡顿：jstack 全量分析要跟上

当 jstack -l 显示无死锁但业务明显卡顿，需人工排查全量 dump：

• 筛选长时间停留在同一行的线程（比如反复出现在某 DAO 方法、某网络 read 调用）
• 检查是否在 I/O（如 socket.read、FileInputStream.read）上阻塞，此时状态多为 WAITING/TIMED_WAITING
• 留意 java.util.concurrent 中的 StampedLock、自旋锁或非公平锁，jstack 无法解析其内部等待逻辑
• JNI 调用中跨语言持锁，jstack 完全不可见，需结合 native 日志或 perf 工具