Java避免死锁关键在于主动规避无期限阻塞：优先用tryLock(long,TimeUnit)超时获取锁，结合统一锁顺序、避免嵌套锁、使用无锁结构，并辅以ThreadMXBean监控与中断机制。
Java 中避免无限死锁等待，关键不是靠“检测死锁后恢复”，而是**主动规避无期限阻塞**——核心手段是使用支持超时的锁申请方式，配合合理的锁设计原则。
用 tryLock(long, TimeUnit) 替代 lock()
这是最直接有效的超时控制方式。ReentrantLock 提供了带超时参数的 tryLock 方法，它不会无条件等待，而是在指定时间内尝试获取锁，超时则返回 false，由你决定后续逻辑（重试、降级、抛异常等）。
- 成功获取锁：返回 true，可安全执行临界区
- 超时未获取到：返回 false，避免线程挂起，便于做失败处理
- 注意：超时时间应结合业务场景设定（如 100ms～2s），太短易频繁失败，太长仍可能拖慢响应
统一锁获取顺序 + 超时兜底
即使用了 tryLock，若多个线程以不同顺序申请多把锁（如线程 A 先锁 obj1 再锁 obj2，线程 B 反之），仍可能在超时前进入环路等待。因此需结合锁顺序约定：
- 为所有可竞争资源定义全局唯一顺序（例如按对象 hashCode 或类名+ID 字符串排序）
- 每次需多锁时，严格按该顺序调用 tryLock，并设置合理超时
- 任一锁获取失败（超时或被中断），立即释放已持有的锁，避免持有部分锁阻塞他人
避免嵌套锁 + 优先使用无锁/乐观策略
很多死锁其实源于过度加锁或锁粒度过粗。与其在死锁边缘加超时补救，不如从源头减少锁依赖：
立即学习“Java免费学习笔记（深入）”；
- 用 AtomicInteger、ConcurrentHashMap 等线程安全类替代手动 synchronized 或 ReentrantLock
- 对读多写少场景，考虑 StampedLock 的乐观读（tryOptimisticRead）+ 验证机制
- 必要加锁时，尽量缩小临界区范围，不把 I/O、远程调用、复杂计算等耗时操作包进锁内
监控与快速失败：ThreadMXBean + 中断协作
超时只是防御一层，还需主动发现潜在问题：
- 定期通过 ManagementFactory.getThreadMXBean().findDeadlockedThreads() 检测死锁（仅用于诊断，不可依赖其恢复）
- 给线程设置合理中断策略：在锁等待中响应 interrupt（tryLock 支持 InterruptedException），上层调用可主动中断长时间卡住的线程
- 记录锁等待日志（如超时前已等待 800ms），帮助定位热点锁和设计瓶颈
