Java多线程死锁本质是循环等待链，重构核心是打破该条件；常用手段包括统一锁获取顺序、改用带超时的ReentrantLock、减少锁粒度、锁分层或资源预检。

Java 中多线程死锁本质不是“资源抢占”失败，而是多个线程因加锁顺序不一致，形成循环等待链。重构代码的核心目标是打破“循环等待”这一可干预的必要条件——其他三个条件（互斥、持有并等待、不可剥夺）通常是并发安全所必需的，一般不破坏。

统一锁获取顺序

这是最直接、最常用的重构手段。为所有共享资源定义明确的全局顺序（如按对象哈希值、类名、或人工编号），强制所有线程按该顺序加锁。

• 例如：规定 lockA 的序号为 1，lockB 为 2，则任何线程都必须先 synchronized(lockA)，再 synchronized(lockB)
• 避免在不同方法中用相反顺序嵌套加锁；可封装成工具方法，如 acquireInOrder(lockA, lockB)，内部按 hashcode 升序自动排序后加锁
• 适用于锁数量固定、资源边界清晰的场景，比如账户转账、库存扣减等双资源操作

改用带超时的显式锁

将隐式 synchronized 替换为 ReentrantLock，配合 tryLock(long, TimeUnit)，让线程在拿不到锁时主动放弃，而非无限阻塞。

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• 加锁失败后需立即释放已持有的锁，并回退业务逻辑（如重试、降级或抛出异常）
• 超时时间不宜过长（如 500ms–2s），既要避免频繁失败，也要防止掩盖真实竞争
• 注意捕获 InterruptedException 并恢复中断状态：Thread.currentThread().interrupt()

减少锁粒度与嵌套层级

很多死锁源于过度同步——把本可独立操作的资源强行绑在一起加锁。重构时应评估是否真需要“同时持有多个锁”。

• 拆分临界区：例如转账操作，可先校验余额（只读锁或无锁），再分别对源账户和目标账户做原子扣增（各自独立加锁）
• 用原子类替代部分锁：如计数器用 AtomicInteger，状态标志用 AtomicBoolean，避免为简单变量引入锁依赖
• 将 synchronized 方法改为同步代码块，仅包裹真正共享写操作的部分

使用锁分层或资源预检机制

在进入多资源操作前，通过非阻塞方式预判资源可用性，避免“先占后等”模式。

• 例如：执行复合操作前，调用 lock.tryLock() 检查所有所需锁是否都能立即获取；任一失败即整体放弃
• 更进一步可设计“锁令牌”机制：由中心协调器统一分配锁序号，线程按序申请，天然杜绝循环
• 适合高一致性要求但并发量可控的后台任务，如配置发布、批量审核等

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南