死锁监控触发阈值为三项指标满足其二：blocked线程超30秒、活跃线程突增50%、cpu
明确死锁监控的触发阈值与响应流程
团队规范不能只写“要监控死锁”，必须定义可执行的红线。例如：线程状态为 BLOCKED 且持续超 30 秒、同一 JVM 内 活跃线程数突增 50% 以上、CPU 使用率低于 10% 同时请求平均耗时翻倍，三项满足其二即自动触发告警。告警信息需包含进程 PID、服务名、部署环境（如 prod-us-east）、最近一次 GC 时间戳，避免排查时反复确认基础信息。
标准化线程快照采集与归档机制
所有线上 Java 服务启动时，必须通过 JVM 参数注入自动采集能力：
-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=/var/log/jvm/%p-jvm.log
同时部署轻量级守护脚本，当检测到 jstack 输出中出现 “Found one Java-level deadlock” 字样时，自动执行：
• 保存当前 threaddump 到 /data/dumps/deadlock_$(date +%s)_%p.log
• 记录对应时刻的 jstat -gc 和 netstat -an | grep :8080 | wc -l 结果
• 将 dump 文件名和时间戳推送至内部钉钉群，并 @SRE 值班人
该脚本需纳入 CI/CD 流水线，在构建镜像阶段强制校验是否存在。
建立线程栈分析 SOP 模板
一线开发收到 dump 文件后，按固定顺序检查三处关键信息：
• 找 “java.lang.Thread.State: BLOCKED (on object monitor)” 行，定位阻塞线程名与等待对象地址（如 0x0000000712345678）
• 往上翻，找该线程最近一次 synchronized 或 Lock.lock() 的调用栈，确认它已持有哪些锁（看 “locked
• 搜索该等待地址是否在其他线程的 “locked” 列表中出现——若 A 等 B、B 等 A，则闭环确认死锁
团队共享一份带注释的示例 dump 分析文档，新成员入职首周必须完成三次模拟分析并提交报告。
代码准入强制锁顺序检查规则
在 SonarQube 中配置自定义规则，扫描所有 synchronized(obj) 和 ReentrantLock.lock() 调用：
• 同一业务模块内，若存在对多个同类资源（如 OrderLock、UserLock）加锁，必须声明全局锁序（如 OrderLock ）
• 若代码中出现嵌套锁且未显式注释锁序（格式为 // LOCK_ORDER: OrderLock → PaymentLock），CI 构建直接失败
• 对外暴露的公共方法（public 修饰且非 static），禁止在方法体内直接 new Object() 作为锁对象——统一使用 @LockResource 注解标注的 Bean 实例。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
