Java死锁排查需沉淀为可执行、可检查、可传承的团队规范，涵盖统一锁获取顺序、线程转储自动化采集、死锁检测纳入每日健康检查、锁粒度与替代方案白名单四条闭环措施。
Java 死锁排查不能靠临时翻文档，必须沉淀为可执行、可检查、可传承的团队规范。核心不是“会不会查”，而是“能不能早发现、快定位、不复发”。以下四条是经多个中大型项目验证落地的关键规范，覆盖从预防到根治的完整闭环。
统一锁获取顺序规范
死锁最常见诱因是多线程以不同顺序申请同一组锁。规范强制要求：所有涉及多个锁的操作，必须按全局约定的资源编号或字母序获取。例如，定义 RESOURCE_A=1，RESOURCE_B=2，则任何代码中出现 synchronized(A) 和 synchronized(B)，必须严格先 A 后 B；若需反向逻辑，应封装为原子方法并加注释说明替代方案。CI 流水线中可接入 Checkstyle 插件，扫描 synchronized 嵌套块的锁对象字面量顺序，对违反者阻断合入。
线程转储自动化采集机制
线上死锁发生时，人工登录服务器执行 jps/jstack 既慢又易出错。规范明确：所有 Java 服务启动时必须配置 JVM 参数 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，并部署轻量级守护脚本。当进程 CPU 持续低于 5% 且活跃线程数突降超 30%（持续 60 秒），自动触发 jstack -l $PID > /var/log/jvm/threaddump_$(date +%s).log，最多保留最近 5 次 dump，并通过企业微信机器人推送告警与文件链接。开发环境也需在 IDE 运行配置中预设 “Dump Threads” 快捷键绑定。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
死锁检测纳入每日健康检查
依赖被动报警太晚。规范要求每个微服务每日凌晨 2 点执行一次主动探测：调用 Spring Boot Actuator 的 /actuator/threaddump 端点（需鉴权），用正则匹配响应体中的 “Found one Java-level deadlock”。若命中，立即标记该服务健康状态为 WARN，并邮件抄送技术负责人与当周 oncall 工程师。该检查结果同步写入内部运维看板，连续 3 天告警即触发架构复审流程。
立即学习“Java免费学习笔记（深入）”；
锁粒度与替代方案白名单
很多“伪死锁”实为长持有锁导致的业务假死。规范明令禁止以下行为：在 synchronized 块内执行 HTTP 调用、数据库查询、文件 IO 或 Thread.sleep()；所有跨系统交互必须移出同步区，改用异步回调或队列解耦。同时提供安全替代清单：优先使用 java.util.concurrent.locks.ReentrantLock 配合 tryLock(timeout)，或直接采用无锁结构如 ConcurrentHashMap、AtomicInteger。新模块设计评审时，必须附《锁策略说明》文档，列明锁对象、作用域、预期持有时间及超时兜底措施。
