死锁预防需从设计阶段切断其四个必要条件：互斥、占有并等待、不可剥夺、循环等待；常用策略包括按序加锁、tryLock超时回退、减小锁粒度、避免嵌套隐式加锁。
死锁在Java中通常发生在多个线程互相持有对方需要的锁，且都不释放，导致所有相关线程永久阻塞。要避免死锁，关键不是等它发生再排查，而是从设计阶段就切断死锁形成的必要条件。
死锁产生的四个必要条件
理解这四点，才能对症下药：
- 互斥条件：资源不能被多个线程同时使用（如synchronized、ReentrantLock默认就是互斥的）
- 占有并等待：线程已持有至少一个锁，又申请新的锁，且不释放已有锁
- 不可剥夺：线程持有的锁不能被其他线程强行抢走（Java中锁默认不可剥夺）
- 循环等待：存在一个线程等待环，比如线程A等B的锁，B等C的锁，C又等A的锁
按序加锁：打破循环等待
最简单有效的预防方式——为所有锁定义全局唯一顺序，所有线程都严格按该顺序获取锁。
例如操作两个账户转账，约定始终先锁id小的账户，再锁id大的：
立即学习“Java免费学习笔记（深入）”；
if (from.getId() < to.getId()) {
synchronized(from) {
synchronized(to) { /* 转账逻辑 */ }
}
} else {
synchronized(to) {
synchronized(from) { /* 转账逻辑 */ }
}
}这样无论哪个线程发起转账，加锁顺序总是一致，循环等待就不复存在。
使用定时锁（tryLock）+回退机制
用ReentrantLock的tryLock(long, TimeUnit)代替无条件阻塞的lock()，给获取锁设置超时。失败后主动释放已持锁，并重试或放弃。
- 避免无限等待，直接打破“占有并等待”和“循环等待”
- 需注意：释放锁必须放在finally块中，防止异常导致锁未释放
- 适合对实时性有要求、能容忍短暂失败重试的场景
减少锁粒度与锁范围
锁得越少、越短，冲突概率越低，死锁机会自然下降：
- 只对真正共享且需同步的代码加锁，避免把数据库查询、日志打印等耗时操作包进同步块
- 优先使用局部变量、ThreadLocal，减少共享状态
- 考虑用ConcurrentHashMap、CopyOnWriteArrayList等线程安全类，替代手动加锁
- 必要时拆分大锁为多个细粒度锁（如按hash分段加锁），但要注意新增锁是否引入新依赖关系
避免嵌套调用中的隐式锁获取
容易被忽视的陷阱：方法A加了锁，内部调用的方法B也尝试获取另一把锁，而B可能被其他线程以不同顺序调用。
建议：
- 公开方法若加锁，内部调用尽量不涉及其他锁；否则明确文档说明加锁契约
- 使用“开放调用”（open call）：在持有当前锁期间，不调用外部可被重写或受控于调用方的方法
- 对第三方库或回调接口，尤其警惕其内部是否可能触发锁竞争
