死锁预防需在架构设计阶段嵌入约束机制：统一资源获取顺序、收敛资源粒度与边界、默认超时与可中断契约、前置可观测性。
死锁预防不能只靠编码规范或事后排查，必须在架构设计阶段就嵌入约束机制。核心思路是：把“破坏死锁四条件”转化为可执行的设计规则，让团队在画模块图、定义接口、划分服务边界时自然避开陷阱。
统一资源获取顺序：从模块契约开始约定
多个服务或模块共用同一组资源（如数据库行锁、分布式锁 key、本地缓存锁）时，必须在架构文档中明确定义全局锁序规则。例如：
- 订单服务与库存服务协作时，所有涉及order_id和sku_id的加锁操作，强制按order_id → sku_id字典序执行
- 在 API 网关层或领域事件总线中注入校验逻辑，对请求携带的资源标识做排序预处理，避免下游模块因参数顺序不一致触发反向加锁
- 使用注解（如 @LockOrder("order_id,sku_id")）配合 AOP，在运行时自动校验加锁顺序，不合规则快速失败而非静默阻塞
资源粒度与边界收敛：减少跨域锁依赖
架构设计时主动收缩锁的作用范围，本质是削弱“持有并等待”和“循环等待”的发生基础：
- 将原本需同时锁定用户账户、积分、优惠券的“原子扣减”操作，拆分为异步补偿流程：先预占（乐观锁+版本号），再异步核销，失败走冲正——用最终一致性替代强一致加锁
- 对高频争用资源（如秒杀商品库存）单独抽离为“库存中心”微服务，对外仅暴露tryLock/confirm/cancel三接口，内部由单线程队列串行处理，彻底消除多线程交叉加锁可能
- 禁止跨服务直接持锁调用；RPC 调用一律视为“不可剥夺”边界，上游完成本地锁释放后再发起远程请求
超时与可中断成为默认契约
在服务间通信和本地同步设计中，把“无超时”视作架构违规：
- 所有分布式锁（Redisson、ZooKeeper）必须配置leaseTime和waitTime，且上线前通过混沌测试验证超时后业务能否安全回退
- 本地 synchronized 块不适用场景，优先采用 ReentrantLock.tryLock(long, TimeUnit)，并在架构模板中固化超时兜底逻辑（如记录告警、降级返回、触发人工介入）
- 消息队列消费者处理含锁逻辑时，设置max.poll.interval.ms小于锁超时时间，确保崩溃后锁能被其他实例接管，打破“不可剥夺”假象
可观测性前置：让死锁风险可建模、可拦截
架构设计阶段就集成死锁防控探针，不是等出问题才看 jstack：
- 在共享基础设施（如通用 DAO 层、锁管理 SDK）中内置锁路径追踪，自动采集thread → lock1 → lock2 → ...调用链，定期上报至监控系统生成锁依赖图谱
- CI/CD 流水线中加入静态分析插件，扫描代码中嵌套 synchronized 或 lock.lock() 的层级与对象类型，对“非固定顺序”模式打标并阻断发布
- 压测环境部署实时检测 agent，当发现线程堆栈持续停留在 wait() / park() 且持有锁超过阈值时，自动 dump 并触发熔断，防止问题扩散到生产
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
