死锁是四个必要条件同时成立的必然结果；互斥条件不可破坏，持有并等待、不可剥夺、循环等待三者任一被破坏即可预防死锁，其中按序加锁是最有效手段。
Java 多线程死锁不是随机发生的，而是四个条件同时成立时的必然结果。只要准确识别并针对性地削弱其中任一条件，就能有效预防。关键不在于背诵条件，而在于理解每个条件在代码中的具体表现和可干预点。
互斥条件：无法消除，但需清醒认知
互斥是锁机制存在的根本目的——比如 synchronized 或 ReentrantLock 本质就是为保证临界区排他访问。这个条件不能也不该被破坏，否则就失去了线程安全的意义。预防思路是：明确哪些资源真需要互斥（如账户余额、库存数量），哪些其实可以无锁（如只读配置、本地缓存计算）。避免“为锁而锁”，把锁粒度控制在真正共享且可变的数据上。
持有并等待：最容易被忽视的隐患源头
这是日常编码中最常踩坑的环节。典型场景是：先锁 A 执行部分逻辑，中间再根据结果决定是否去锁 B；或在方法调用链中层层加锁，但释放时机不统一。预防办法包括：
- 尽量采用“一次性申请”策略：例如转账操作，统一按账户 ID 小到大顺序获取两个账户锁，不满足就不拿，避免半途卡住
- 使用带超时的锁（lock.tryLock(timeout, unit)）：若等待指定时间未获锁，主动释放已持锁并回退，打破“持有+等待”的闭环
- 避免在同步块内调用外部方法（尤其是可能加锁的第三方方法），防止隐式等待
不可剥夺：用可中断机制补足语言限制
Java 的 synchronized 不支持中断，一旦阻塞就只能等；而 ReentrantLock 提供了 lockInterruptibly()。这意味着当线程被中断时，它会主动放弃等待，并抛出 InterruptedException。这相当于在逻辑层面模拟了“可剥夺”——不是系统强抢，而是让线程响应中断后自行清理和退出。实际应用中应结合超时与中断双保险，尤其在线程池任务中必须处理中断信号。
立即学习“Java免费学习笔记（深入）”；
循环等待：最可控、最推荐的突破口
只要所有线程以相同全局顺序申请锁，循环等待就不可能形成。这是预防成本最低、效果最稳的方式。例如：
- 对锁对象定义自然序：按类名+ID哈希值排序，或约定 resourceA 总在 resourceB 之前获取
- 封装成工具方法：acquireInOrder(lock1, lock2, lock3)，内部自动排序并加锁
- 在设计阶段就约定资源获取协议，比如 DAO 层操作总是先锁用户表、再锁订单表，不许反向
这种约定看似简单，却能覆盖绝大多数业务场景下的死锁风险。
