lockInterruptibly()可中断等待锁的线程，使其响应interrupt()并抛出InterruptedException，从而避免无限阻塞；而lock()无视中断，易导致死锁僵局。

用 lockInterruptibly() 防止线程无限等待死锁，核心是让等待锁的线程能被主动“叫停”，而不是卡在 Blocked 状态里动弹不得。它不解决死锁本身，但能打破死锁僵局，给系统留出恢复余地。

为什么普通 lock() 容易陷入死锁僵局

调用 lock() 获取锁失败时，线程会一直阻塞，完全忽略中断信号。比如两个线程交叉持有并申请对方的锁（线程 A 持 lock1 申请 lock2，线程 B 持 lock2 申请 lock1），双方都卡住，谁也不放手——这就是典型不可解的死锁状态。

• synchronized 同样无法响应中断，行为一致
• 这种“只等、不退、不响应”的机制，在高并发或资源紧张场景下极易导致服务假死

lockInterruptibly() 是怎么破局的

该方法让线程在等待锁的过程中保持对中断信号的敏感性。一旦被其他线程调用 interrupt()，它不会继续傻等，而是立即抛出 InterruptedException，退出阻塞，并释放当前已持有的锁（如果有的话）。

• 抛异常后，线程可执行清理逻辑：关闭连接、回滚事务、记录日志
• 关键点：它中断的是“等待锁的线程”，不是“持有锁的线程”；持有锁的线程不受影响，仍正常执行
• 配合 try-catch 使用，确保异常不被吞掉，否则中断效果失效

实际使用要点

必须在 try 块外获取锁，且在 finally 中显式 unlock()，同时捕获 InterruptedException 并合理处理：

• 不要在 catch 中静默吞掉异常，至少要重新设置中断状态：Thread.currentThread().interrupt();
• 若持有多个锁，建议按固定顺序申请（如 always lock1 before lock2），再配合 lockInterruptibly()，双重降低死锁概率
• 避免在 synchronized 块内混用 ReentrantLock，容易引发锁粒度混乱和释放遗漏
• 注意：lockInterruptibly() 和 tryLock(long, TimeUnit) 可组合使用——先尝试限时获取，超时后再决定是否中断重试

对比其他防死锁手段

lockInterruptibly() 不是万能钥匙，但它比纯靠运气的“随机中断”或“暴力 kill 进程”更可控：

• vs tryLock(timeout)：后者是时间维度的防御（等够久就放弃），前者是事件维度的响应（一收到中断就退出）
• vs 死锁检测+自动恢复：JVM 不提供内置死锁自动解除机制，lockInterruptibly() 是开发者可主动触发的轻量级干预手段
• vs 公平锁：公平锁只改变排队顺序，不能避免死锁；lockInterruptibly() 则赋予了外部干预能力