如何利用 lockInterruptibly 提高长时间变量占位中的中断处理灵活性？

本文共计531个文字，预计阅读时间需要3分钟。

当某个线程长时间持有锁（例如因逻辑缺陷未释放、或执行耗时操作），其他线程调用 `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()：从排队第一秒起就响应中断，真正实现“等待可取消”

它不是让持有锁的线程被中断，而是让“还没拿到锁”的线程及时止损。