最直接有效的方式是强制所有线程按统一、全局固定的顺序获取锁，从根源上切断循环等待链；需为每把锁赋予稳定唯一编号（如用户锁=100、订单锁=200），严格按升序申请并逆序释放，作用域最小化，跨服务亦需协同编号规则。
最直接有效的方式是强制所有线程按统一、全局固定的顺序获取锁，从根源上切断循环等待链。
锁对象必须可比较且标识唯一
每把锁需具备稳定、不可变的排序依据，不能依赖运行时动态生成的值。例如：
- 用预定义整数编号代替对象hashCode——因为new Object()每次生成不同hashCode，无法跨线程对齐顺序
- 避免拼接字符串作为锁名（如"order_"+orderId），不同线程传入不同orderId会导致实际锁序错乱
- 推荐做法：将核心资源映射到静态常量池，比如用户锁=100、订单锁=200、库存锁=300，并在系统文档中固化该编号表
所有代码路径严格遵循升序申请
无论模块、服务或调用栈深浅，只要涉及多锁操作，就必须按编号从小到大依次加锁：
- 涉及R1（100）、R2（200）、R3（300）时，只允许 R1→R2→R3，禁止跳过R2直取R3，更不允许逆序（如R2→R1）
- 可封装工具方法，接收锁对象列表后自动排序再逐个acquire，减少人工疏漏
- 数据库操作同步适配：UPDATE多行时按主键ID升序执行，或固定WHERE条件使扫描顺序一致，规避间隙锁交叉
释放顺序与作用域必须同步收紧
仅控制获取顺序还不够，还需约束持有行为：
- 释放顺序应与获取顺序相反（后锁先放），虽不直接防死锁，但能加快资源归还，缩短“持旧等新”窗口
- 锁的作用范围必须最小化——只包裹真正需要同步的代码段，避免在synchronized块内调用可能触发新锁的方法
- 优先使用显式Lock + try-finally 或 try-with-resources，确保异常时仍能释放，杜绝因未unlock导致的隐性阻塞
跨服务/分布式场景同样适用
单进程内有序只是基础，微服务架构下更需全局协同：
- 在API契约或上下游协作规范中明确要求：凡涉及多资源变更的操作，必须按编号表顺序申请锁或数据库行锁
- 若使用分布式锁（如Redis RedLock），也应将资源编号嵌入锁key设计，例如 lock:order:200:user:100，确保排序逻辑可传递
- 一致性哈希锁池是实用折中方案：预分配100个Lock对象，按 resourceKey % 100 映射，既避免锁爆炸，又保障同key始终命中同一把锁
