jstack -l 可快速抓取线程快照并识别死锁，输出中出现“Found 1 deadlock.”即表明检测到循环等待导致的死锁，但仅覆盖synchronized和JUC显式锁，不包括StampedLock、外部资源锁等。
用 jstack 快速抓取线程快照并识别死锁
Java 自带的 jstack 是最直接、最低侵入的死锁定位工具。只要进程还在运行，就能立刻获取当前所有线程的状态和锁持有关系。
执行命令：
jstack -l其中
-l 参数关键——它会输出显式锁（ReentrantLock 等）的持有者和等待者，没有这个参数会漏掉大部分非 synchronized 死锁。
输出中一旦出现 Found 1 deadlock. 字样，后面会明确列出互相等待的线程栈、各自持有的锁和正在等待的锁。注意：这个提示只在 JVM 检测到「循环等待」时才打印，不是所有死锁都能被自动发现（比如涉及外部资源或自定义锁逻辑时）。
- 确保用启动 Java 进程的同一用户执行
jstack，否则可能权限拒绝 - 如果进程无响应但
jstack报错「unable to open socket file」，可能是临时目录被清理，可尝试加-J-Djava.io.tmpdir=/tmp - 线上环境慎用
jstack -F（强制模式），可能引起短暂 STW，尤其在 GC 压力大时
通过 ThreadMXBean 在代码中主动检测死锁
适合嵌入监控系统或测试阶段主动扫描，比人工 jstack 更可控。JDK 提供了 ThreadMXBean 接口，其 findDeadlockedThreads() 方法能返回当前 JVM 中所有陷入死锁的线程 ID 数组。
立即学习“Java免费学习笔记（深入）”；
示例代码：
ThreadMXBean mxBean = ManagementFactory.getThreadMXBean();
long[] deadlockedIds = mxBean.findDeadlockedThreads();
if (deadlockedIds != null && deadlockedIds.length > 0) {
ThreadInfo[] infos = mxBean.getThreadInfo(deadlockedIds, true, true);
for (ThreadInfo info : infos) {
System.err.println("Deadlocked thread: " + info.getThreadName());
System.err.println("Stack trace:\n" + Arrays.toString(info.getStackTrace()));
}
}
注意：findDeadlockedThreads() 只检测「synchronized 和 java.util.concurrent.Lock 的组合死锁」，不包含 StampedLock、ReadWriteLock 的读锁重入场景，也不覆盖 native 锁或数据库行锁等外部依赖。
- 该方法是轻量级的，但频繁调用（如每秒多次）仍会带来一定开销
- 返回
null不代表绝对无死锁，只是 JVM 未检测到符合内置规则的循环等待 - 配合
getThreadInfo(..., true, true)才能拿到锁信息和完整栈，两个true缺一不可
使用 JMC 或 VisualVM 查看锁竞争热点
当死锁尚未发生，但已有明显线程阻塞或响应变慢时，需要观察锁的争用趋势。JMC（Java Mission Control）或 VisualVM 的 MBean 插件能实时显示 java.lang:type=Threading 下的锁统计。
重点关注三个指标：CurrentThreadCpuTime（是否某线程长期占用 CPU）、ThreadContentionMonitoringEnabled（需开启）、以及 PeakThreadCount 是否异常飙升。更实用的是「Sampler → Lock Instances」视图，它能列出被最多线程等待的锁实例（按 class+identity hash）。
- JMC 默认不开启锁监控，需在启动 JVM 时加参数：
-XX:+UnlockCommercialFeatures -XX:+FlightRecorder -XX:+FlightRecorderOptions=settings=profile - VisualVM 需安装「Threads» 插件，并勾选「Enable thread contention monitoring」
- 看到某个
ReentrantLock实例的queueLength持续 >5，且对应线程栈总卡在lock()，大概率是锁粒度太粗或存在单点瓶颈
避免死锁的编码习惯比事后排查更重要
90% 的死锁源于可预测的模式：多把锁的获取顺序不一致、锁内调用外部方法、或在持有锁时等待条件变量。排查永远滞后于预防。
几个具体约束建议：
- 所有涉及多把锁的操作，统一按「类名字母序 + 字段名」硬编码顺序获取，例如先
synchronized(A.class)再synchronized(B.class)，杜绝动态决定顺序 -
synchronized块内禁止调用可能被子类重写的非 final 方法，防止隐式锁升级或回调死锁 - 用
tryLock(timeout, TimeUnit)替代无超时的lock()，并在超时后主动释放已持锁（需手动管理锁顺序） - 对
ConcurrentHashMap等线程安全容器，别误以为「不用锁」就绝对安全——它的迭代器弱一致性可能引发业务逻辑死锁（如遍历时修改触发 rehash，又在监听器里反向调用）
真正棘手的死锁往往藏在框架回调、代理增强、或跨 JVM 资源协调里，这时候 jstack 看不到锁，ThreadMXBean 也查不到——得结合日志埋点、分布式追踪 ID 和数据库锁视图交叉分析。
