Java死锁无法完全避免，但可通过破坏互斥、请求并保持、不可剥夺、循环等待四大条件来显著降低概率：如用ConcurrentHashMap替代加锁HashMap、tryLock超时机制、lockInterruptibly中断等待、按序号强制锁获取顺序。
Java 线程死锁无法“完全避免”，但可以通过**有意识地破坏死锁的四大必要条件之一**，显著降低发生概率。关键不是等死锁出现再排查，而是从设计源头削弱其滋生土壤。
破坏“互斥条件”：减少独占资源，用可重入或无锁结构
互斥是大多数锁的天然属性，完全消除不现实，但可缩小其范围：
-
优先使用线程安全且无锁的数据结构：如
ConcurrentHashMap、AtomicInteger替代加锁的HashMap + synchronized；它们内部通过 CAS 或分段机制实现并发，不依赖传统互斥锁。 -
把大锁拆成小锁，降低资源粒度：例如缓存系统中，不要对整个缓存对象加一把全局锁，改为按 key 的 hash 分段加锁（类似
ConcurrentHashMap的思想），让线程只竞争局部资源。 - 能用不可变对象就不用可变共享对象：String、LocalDateTime 等不可变类天然线程安全，无需互斥控制。
破坏“请求并保持”：一次性申请全部资源，或主动释放已占资源
这是最常用、最有效的防死锁策略——杜绝“边拿边要”的行为模式：
-
显式使用
tryLock(timeout)：给锁获取设置超时，失败则释放已持锁并重试或回退。例如两个账户转账，先尝试获取 accountA 和 accountB 的锁，任一失败就全部放弃，稍后重试。 - 约定资源获取顺序（全局排序）：对所有可能被多线程竞争的资源定义唯一 ID（如账户 ID 按升序），强制所有线程按相同顺序加锁。这样就不会出现 A 线程持 A 锁等 B，B 线程持 B 锁等 A 的循环等待。
-
使用
java.util.concurrent.locks.ReentrantLock的lockInterruptibly()：配合中断响应，让线程在等待锁时可被外部打断，避免无限期挂起。
破坏“不可剥夺”：用可中断/可超时的锁机制替代原生 synchronized
synchronized 是不可剥夺的——一旦进入等待队列，只能等持有者释放。而 ReentrantLock 提供了剥夺可能性：
立即学习“Java免费学习笔记（深入）”；
-
用
lockInterruptibly()替代lock()：当线程在等待锁时，其他线程可通过interrupt()打断它，从而退出等待、释放已占资源、避免僵持。 -
结合超时与回退逻辑：比如调用
tryLock(1, TimeUnit.SECONDS)，超时后主动释放已获取的锁，并记录失败，避免陷入“死等”状态。 - 避免在 synchronized 块内执行耗时操作（如 I/O、远程调用）：这会人为延长持有锁时间，增加被剥夺前的等待窗口，间接强化不可剥夺性。
破坏“循环等待”：引入全局资源序号，强制单向依赖
循环等待是死锁的直接表现形式，也是最容易工程化约束的一环：
- 为每个锁对象分配唯一、可比较的序号（如数据库主键、对象哈希码、自增 ID），要求线程必须按序号从小到大依次获取锁。
-
封装成工具方法，避免人工出错：
public static void lockInOrder(Lock... locks) throws InterruptedException { Arrays.sort(locks, Comparator.comparing(l -> System.identityHashCode(l))); for (Lock lock : locks) lock.lock(); } - 在分布式场景中，可用 Redis 或 ZooKeeper 实现全局有序锁协调器，确保跨 JVM 的锁获取也遵循统一顺序。
