lockInterruptibly()能打破“死等”困局：等待锁的线程一旦被中断即退出排队，避免空耗；适用于用户取消、接口超时、Future.cancel(true)、shutdownNow()等需主动终止等待的场景；必须配合try-catch-finally三段式结构使用。
lockInterruptibly 能打破“死等”困局
当某个线程长时间持有锁（比如因逻辑缺陷未释放、或执行耗时操作），其他线程调用 lock() 就只能无限期阻塞，JVM 不会报死锁，监控工具也难定位——它只是安静地卡在 Blocked 状态。而 lockInterruptibly() 在此时就体现出关键价值：等待中的线程一旦被中断，立刻退出排队、不继续傻等，避免资源空耗和响应停滞。
适用于需主动终止等待的典型场景
以下情况必须用 lockInterruptibly()，而不是 lock()：
- 用户点击取消按钮，后台任务需立即中止等待锁并清理状态
- HTTP 接口设置了超时（如 5 秒），请求到期后应中断仍在争锁的线程
- Spring 的 @Async 方法被 Future.cancel(true) 调用时，需让锁等待配合中断退出
- 定时任务调度器执行 shutdownNow()，要求所有待锁线程快速响应、不拖尾
正确写法必须带防御性结构
仅调用 lockInterruptibly() 不够，必须严格遵循三段式结构：
- try 块中调用 lockInterruptibly()，执行临界区逻辑
- catch 捕获 InterruptedException，立即恢复中断状态（Thread.currentThread().interrupt()），然后退出或抛异常
- finally 中检查 lock.isHeldByCurrentThread()，仅在已持锁时才调用 unlock()，防止未持锁却 unlock 导致 IllegalMonitorStateException
与 synchronized 和 lock() 的本质区别
对比更清晰：
- synchronized：完全无视中断，等待 monitor 过程中 interrupt() 被静默吞掉
- lock()：屏蔽中断直到获锁成功，再抛 InterruptedException——但此时已晚，可能已错过业务退出时机
- lockInterruptibly()：从排队第一秒起就响应中断，真正实现“等待可取消”
它不是让持有锁的线程被中断，而是让“还没拿到锁”的线程及时止损。
