用 jstack -l 可快速发现死锁，输出末尾显示“Found 1 deadlock.”即确认；它会列出锁持有者与等待者地址，匹配locked 和waiting to lock 即可定位。
怎么用 jstack 快速发现死锁
直接运行 jstack -l <pid></pid>，加上 -l 参数是关键——它会显式列出锁持有者和等待者，没有这个参数，jstack 默认不输出死锁相关线索，容易漏掉问题。
常见错误现象：只跑 jstack <pid></pid>，看到一堆 WAITING 线程就以为是卡顿，其实根本没触发死锁检测逻辑；或者导出文本后手动 grep “deadlock”，结果一无所获。
-
jstack -l <pid></pid>输出末尾如果有 “Found 1 deadlock.” 就是实锤，不用再猜 - 如果 JVM 是 8u60+，
jstack -l还会标出每个线程持有的java.util.concurrent.locks.ReentrantLock和synchronized锁，区分得很清楚 - 线上环境别反复执行
jstack -l，它会触发全局 safepoint，短时间高频调用可能加重 STW 延迟
死锁堆栈里怎么看谁锁了谁
重点盯住 java.lang.Thread.State: BLOCKED (on object monitor) 和 Locked ownable synchronizers: 这两块。前者告诉你线程在等哪个对象监视器，后者告诉你它自己正拿着哪些锁。
使用场景：两个线程互相等待对方释放锁，比如线程 A 持有 lockA 等 lockB，线程 B 持有 lockB 等 lockA。这时候 jstack -l 会把双方的 waiting to lock 和 locked 地址列出来，地址一致就对上了。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 注意看
locked和waiting to lock的十六进制地址是否匹配 -
java.util.concurrent.locks.ReentrantLock$NonfairSync类型的锁，要看locked ownable synchronizers下的owner thread字段，不是看 monitor - 如果看到
parking to wait for，那是Unsafe.park()，属于 AQS 队列阻塞，不等于死锁，别误判
为什么 jstack 有时找不到死锁
不是所有“卡住”都是死锁。jstack -l 只能检测到 **循环等待且全部线程都处于 BLOCKED 或 WAITING（并明确指向同一把锁）** 的经典死锁。其他情况它不报。
性能 / 兼容性影响：JDK 6 和 7 的 jstack -l 对 ReentrantLock 支持弱，可能只显示 AbstractOwnableSynchronizer，看不出具体锁实例；JDK 8u60 后才稳定输出 owner thread ID。
- 线程在 I/O、
Thread.sleep()、Object.wait()（无竞争）中挂起 → 不是死锁，jstack不报 - 三方库用了
LockSupport.park()自定义同步，没走 JVM 锁机制 →jstack -l看不到锁关系 - 分布式锁、数据库行锁、文件锁这类外部资源争用 →
jstack根本不感知
自动检测死锁的靠谱做法
别依赖人工翻日志。JVM 自带的 ThreadMXBean.findDeadlockedThreads() 是唯一可靠入口，所有监控工具（如 Prometheus + JMX Exporter、Arthas）底层都调它。
可给出简短示例：
ThreadMXBean bean = ManagementFactory.getThreadMXBean();
long[] ids = bean.findDeadlockedThreads(); // 返回 null 表示没死锁
if (ids != null) {
ThreadInfo[] infos = bean.getThreadInfo(ids, true, true);
// 打印 infos 就是 jstack -l 末尾那段
}- Arthas 的
thread -b命令就是封装了这个 API，比手敲jstack快，还支持持续 watch - Spring Boot Actuator 的
/actuator/threaddump默认不包含死锁检测，得加配置management.endpoint.threaddump.show-locks=true - 注意
findDeadlockedThreads()是快照操作，瞬间发生又解开的死锁可能错过，得配合定期轮询或告警触发
死锁真正难的不是发现，是复现和定位锁顺序——jstack 给的是结果快照，但谁先 lockA 再 lockB、谁反过来，得结合代码路径和调用时序推。这点很容易被忽略。
