最直接有效的方式是强制所有线程按统一、全局固定的顺序获取锁。通过为每把锁赋予唯一可比较标识（如hashcode、预定义编号），严格按升序申请，并在系统层面约定全局编号表，配合释放顺序相反、作用域收缩及静态化锁对象，从根源上切断循环等待链。
最直接有效的方式是强制所有线程按统一、全局固定的顺序获取锁，从而从根源上切断循环等待链。
锁序固化：用资源标识建立唯一先后关系
给每把锁赋予一个不可变的、可比较的标识（如对象hashCode、字符串名称、预定义编号），所有线程严格按该标识升序（或降序）依次申请。例如：
- 锁A的hashCode = 1024，锁B的hashCode = 2048 → 所有代码必须先lock(A)，再lock(B)
- 若涉及三把锁，编号为R1、R2、R3 → 每次都按 R1→R2→R3 顺序加锁，绝不跳序或逆序
- 实际编码中可封装工具方法，自动对锁列表排序后再逐个acquire，避免人工出错
跨模块/跨服务也要保持锁序一致
单进程内统一还不够，分布式或多模块协作时更需约定：
- 在系统设计文档中明确定义核心资源的全局编号表（如：用户锁=100，订单锁=200，库存锁=300）
- 不同微服务调用链中，凡涉及多资源操作，均须遵守该编号顺序申请锁或数据库行锁
- 数据库层面同样适用：UPDATE语句按主键ID升序更新多行，或固定WHERE条件的扫描顺序，减少索引间隙锁交叉
配合释放顺序与作用域收缩
仅控制获取顺序还不够，需同步规范释放和持有行为：
- 释放顺序应与获取顺序相反（后锁先放），虽不防死锁但利于资源及时归还
- 锁的作用范围尽量窄——只在真正需要同步的代码段加锁，避免“持旧等新”时间过长
- 不用嵌套synchronized块，改用显式Lock+try-finally或try-with-resources管理，确保异常时仍能释放
警惕伪有序：动态锁名或运行时生成锁对象的风险
以下做法看似有序，实则可能失效：
- 用new Object()创建锁 → 每次hashCode不同，无法保证跨线程顺序一致
- 锁名来自变量拼接（如"order_"+orderId）→ 不同线程传入不同orderId，导致实际锁序混乱
- 正确做法：锁对象应静态常量化，或通过一致性哈希映射到固定锁池（如100个预分配Lock对象，按key%100选取）
