用 jstack -l 可让 jvm 主动检测死锁并标出循环等待关系；仅 jstack 不触发分析，-l 参数不可省；输出末尾“found one java-level deadlock”即确认死锁，否则仅说明无 jvm 级死锁。
直接用 jstack -l
用对命令：-l 参数不可省
只运行 jstack <pid></pid> 只会输出所有线程的原始堆栈，不触发死锁分析；加上 -l（小写 L）参数后，JVM 会扫描锁持有与等待关系，并在输出末尾显式标记：
- 出现 “Found one Java-level deadlock” 区块，说明检测到死锁
- 若显示 “No deadlocks found”，不代表没阻塞问题，只是没满足 JVM 级死锁判定条件（比如非 synchronized 锁、native 层锁、I/O 阻塞等）
- 建议将结果重定向保存：
jstack -l <pid> > deadlock.log</pid>，方便后续逐行查看
看懂死锁区块：锁定交叉等待链
在 “Found one Java-level deadlock” 下方，会列出所有卷入死锁的线程。每个线程段里重点关注两行：
- locked ：该线程当前持有的锁对象地址
- waiting to lock ：它正在阻塞等待获取的另一个锁地址
如果线程 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 工具
