防范死锁的核心是打破循环等待，需全局统一锁顺序、用trylock+超时兜底、缩小锁粒度、运行时检测。
防范因锁顺序错误引发的死锁，核心是打破“循环等待”这一必要条件。只要所有线程对同一组资源始终按**全局一致、可预测、不可变**的顺序加锁，就能从根源上消除经典隐蔽死锁。
统一锁获取顺序（最直接有效）
这是预防此类死锁的基石策略。关键不是“谁先谁后”，而是“所有人必须同序”。
- 为每个待锁定对象分配唯一且稳定的排序依据，例如：System.identityHashCode(obj)（比 toString() 更可靠，不受重写影响）
- 若涉及多个业务对象（如 user、order），不直接对其加锁，而是封装成专用锁对象，并基于其 ID 或类型名做字典序/数值序排序
- 在真正加锁前，先将所有待锁对象放入 List，调用 Collections.sort() 排序，再依次 lock()
- synchronized 块无法动态排序，该策略天然适配 ReentrantLock；若必须用 synchronized，需在设计阶段就约定好嵌套层级和顺序（如 always lock User.class before Order.class）
用 tryLock + 超时主动规避阻塞
即使顺序一致，网络抖动、GC 暂停等也可能导致短暂争抢。tryLock 是防御性兜底手段。
- 绝不连续调用 lock.lock() 获取多把锁——第二把失败时第一把可能已持有，造成资源独占却无法推进
- 正确做法：每把锁都用 tryLock(timeout, unit)，任一失败则立即释放已获锁，并退避重试
- 退避时间建议加随机扰动（如 10–100ms），避免多个线程同步重试形成新竞争热点
- 注意：synchronized 没有超时能力，必须切换到 ReentrantLock 才能启用此机制
缩小锁粒度与解耦锁边界
很多“锁顺序问题”其实源于过度锁定——本可分段操作，却用一把大锁包到底。
- 把一个长临界区拆成多个短临界区，中间插入非同步逻辑，降低同时持有多锁的概率
- 区分读写场景：读操作尽量用无锁结构（ConcurrentHashMap）、CopyOnWriteArrayList 或读写锁（ReentrantReadWriteLock）
- 避免在持锁期间调用外部方法（尤其是可能反向加锁的回调、RPC、数据库事务），否则锁边界失控，顺序约定形同虚设
运行时检测与上线防护
开发阶段难穷尽所有路径，生产环境需要可观测性兜底。
- 定期调用 ThreadMXBean.findDeadlockedThreads() 主动扫描，配合告警（注意：它只捕获 Java-level 死锁，不包括数据库锁）
- 上线前用 jstack
抽样检查线程堆栈，搜索 “deadlock” 关键字，确认无循环等待链 - 在关键锁操作附近打日志（如 “acquiring lock on order-12345”），便于事后还原加锁序列，验证是否真按序执行
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
