lockInterruptibly会在等待锁时响应中断，而lock不会；线程未获锁时被interrupt()即抛InterruptedException退出等待，已持锁线程不受影响；必须用try-catch-finally确保unlock并恢复中断状态。
lockInterruptibly 会在等待锁的过程中响应中断，而普通 lock 不会。 它让线程在被阻塞等待锁时，能及时感知并处理 Thread.interrupt()，避免无限期挂起。
什么时候会响应中断
调用 lockInterruptibly 后，如果当前线程尚未获取到锁，且在此期间被其他线程调用 interrupt()，它会立即抛出 InterruptedException 并退出等待，不会获得锁。已经持有锁的线程调用 interrupt() 不影响锁本身，只影响后续等待者。
- 线程 A 调用 lockInterruptibly，发现锁被占用，进入等待队列
- 线程 B 在此时调用 threadA.interrupt()
- 线程 A 立即从等待中醒来，抛出 InterruptedException，不获取锁
和普通 lock 的关键区别
普通 lock 方法在等待锁时会忽略中断信号，即使被 interrupt()，仍继续阻塞直到获取锁成功才返回。lockInterruptibly 则把中断作为合法的退出条件之一，更符合协作式中断的设计原则。
- lock()：中断只是“标记”，线程醒来后继续等，直到抢到锁
- lockInterruptibly()：中断是“指令”，线程立刻放弃等待，抛异常
使用时要注意什么
必须在 try-catch 中捕获 InterruptedException，并合理处理——比如清理资源、重置状态或向上层传播。不能简单吞掉异常，否则会丢失中断意图；也不能在 catch 中忽略中断状态，建议调用 Thread.currentThread().interrupt() 恢复中断标志。
立即学习“Java免费学习笔记（深入）”；
- 不要空 catch（e.g. catch (InterruptedException e) {}）
- 若无法立即处理，应重新设置中断状态：Thread.currentThread().interrupt()
- 确保 unlock() 在 finally 块中执行，防止因异常导致锁未释放
典型适用场景
适用于需要支持超时、取消或与其它可中断操作（如 Future.cancel、ScheduledExecutorService.shutdownNow）协同的业务逻辑，比如任务调度、带截止时间的资源获取、用户主动取消长时间操作等。
- 网络请求中等待数据库连接池资源
- 批量任务中某个子任务被外部取消
- GUI 应用中用户点击“停止”按钮时中断后台锁等待
