lockinterruptibly()仅在等待锁时响应中断，成功获取锁后不检查中断状态；必须配合try-catch处理interruptedexception，恢复中断标志并清理资源；需用isheldbycurrentthread()判断是否持锁再unlock。
lockInterruptibly 会响应中断，但只在等待锁时生效
调用 lockInterruptibly() 后，如果锁已被占用，线程会进入阻塞等待；此时若其他线程调用该线程的 interrupt()，它会立即抛出 InterruptedException 并退出等待，而不是继续傻等。但要注意：如果锁**当前可用**，lockInterruptibly() 会直接获取锁并返回，根本不会检查中断状态——也就是说，**加锁成功前的中断标志会被忽略**。
常见错误是先调用 Thread.interrupted() 或检查 isInterrupted()，再决定是否加锁，这其实没必要；真正要关注的是“等锁过程中能否被叫停”。
必须配合 try-catch 使用，且不能吞掉 InterruptedException
lockInterruptibly() 是受检异常方法，编译器强制你处理 InterruptedException。错误做法是捕获后空 catch 或仅打日志就继续执行——这等于废掉了中断机制。
- 正确做法：捕获后通常应清理资源、恢复中断状态（调用
Thread.currentThread().interrupt()），然后退出当前逻辑 - 不要在 catch 块里调用
lock()回退，那会再次失去中断响应能力 - 如果业务允许重试，需明确设计重试边界，比如限定最多尝试 3 次，每次间隔 + 超时控制
示例片段：
try {
lock.lockInterruptibly();
// 执行临界区操作
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断标记
throw new RuntimeException("acquire lock interrupted", e);
} finally {
if (lock.isHeldByCurrentThread()) {
lock.unlock();
}
}
和 synchronized 对比：中断响应能力差异明显
synchronized 关键字完全不响应中断：一旦进入等待队列（如 Monitor Enter queue），即使被中断，也只会设置中断标志，线程仍会一直等到锁释放并抢到锁才继续执行。而 ReentrantLock.lockInterruptibly() 是少数能真正在锁竞争阶段尊重 interrupt() 的标准机制。
适用场景包括：
- 带超时的协作式任务取消（比如定时任务中用户主动取消）
- 线程池中 worker 线程被 shutdownNow() 中断时，需快速释放锁并退出
- 测试中模拟中断路径，验证资源清理逻辑是否健壮
注意：lockInterruptibly() 不影响锁的可重入性或公平性配置，公平锁下它仍遵循 FIFO 队列顺序，只是队列中的线程可以被提前唤醒并抛异常。
容易忽略的 cleanup 和锁持有状态判断
很多人以为只要进了 catch 就说明没拿到锁，于是跳过 unlock()。这是错的——InterruptedException 只会在**等待过程中**抛出，一旦成功获得锁，就不会因中断而自动释放。所以必须靠 lock.isHeldByCurrentThread() 判断是否真的持有了锁，再决定是否 unlock()。
另一个坑是：在 finally 块里无条件 unlock()，会导致 IllegalMonitorStateException。务必加持有检查，哪怕多一次 volatile 读开销也值得。
复杂点在于，中断可能发生在临界区执行中途（比如 IO 阻塞时），这时候锁还在手里，但业务逻辑已不可继续——所以「响应中断」不只是等锁阶段的事，整个流程得有统一的中断感知设计，不能只靠 lockInterruptibly() 一招打天下。
