生产环境死锁需早发现、快定位、自动响应，核心是将JVM死锁信号转为可监控运维事件：实时用ThreadMXBean每30秒探测，结合jstack兜底、APM指标联动预警，并分级告警处置。
生产环境死锁必须“早发现、快定位、自动响应”，不能靠人工查日志或等用户投诉。核心是把 JVM 层的死锁信号，变成可监控、可告警、可追溯的运维事件。
实时检测：用 ThreadMXBean 主动轮询
JVM 原生支持死锁探测，无需额外依赖。通过 ThreadMXBean.findDeadlockedThreads() 可在毫秒级识别 Java-level 死锁：
- 每 30 秒执行一次探测（太频繁影响性能，太长会延迟告警）
- 若返回非 null 数组，立即触发告警并调用 getThreadInfo(deadlockedThreads, Integer.MAX_VALUE) 获取完整堆栈
- 将线程名、锁对象地址、等待链路写入统一日志（如 SLF4J + Logback 的 JSON layout），便于 ELK 或 Prometheus+Loki 检索
线程快照兜底：jstack 自动化采集
ThreadMXBean 只能捕获 JVM 级死锁，对 Native 层阻塞、JNI 锁、或 jstack 能识别但 MXBean 漏检的边缘 case 需补充：
- 配置定时任务（如 Linux cron 或 Spring Scheduler），每 2 分钟执行 jstack -l
，输出带锁信息的线程快照 - 用脚本解析输出中是否含 "Found one Java-level deadlock" 或循环出现 "waiting to lock" 与 "which is held by"
- 命中即归档快照文件，并推送告警（含进程 PID、时间戳、快照路径）
APM+指标联动：从现象反推死锁风险
死锁发生时，往往伴随可观测性指标异常，可作为前置预警信号：
- 监控 线程池活跃线程数持续 ≥ 核心数 × 1.8 且队列堆积（说明大量线程卡在锁上）
- 追踪 平均锁等待时间（Lock Wait Time）突增 > 300ms（Arthas、Micrometer 或 SkyWalking 支持）
- 观察 CPU 使用率未升高但 HTTP 5xx/超时激增，排除下游故障后，高度疑似本地锁争用
- 这些指标达到阈值时，自动触发一次 ThreadMXBean 探测 + jstack 快照，形成“预警→确认→取证”闭环
告警与处置：分级响应不升级
告警不是发给所有人，而是按严重程度分流：
- P0 级（已死锁）：企业微信/钉钉强提醒 + 电话；附带快照链接和锁循环图（可用 jstack 输出自动生成简易 dependency graph）
- P1 级（高风险）：BLOCKED 线程数 > 20 且持续 1 分钟，或锁等待 P95 > 500ms —— 发送至值班群，提示“请检查最近上线代码中嵌套 synchronized 或 lock 顺序”
- P2 级（预防）：静态扫描发现 同一类中多个 synchronized 方法交叉调用外部服务，纳入代码门禁（如 SonarQube 规则），阻断合入
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
