Java ReentrantLock.lockInterruptibly 如何避免线程永久等待：中断响应与业务回滚

库存服务正在给同一个 SKU 做扣减时，取消信号到了，排队线程却还卡在 lock() 外面。线程池看到的是“任务还活着”，业务看到的却是订单已经失去处理窗口。Java 的 ReentrantLock.lockInterruptibly() 可以把这段等待变成可中断等待，但它只负责把中断送到锁边界，库存状态、异常传播和回滚仍要由业务代码完成。

需要让排队中的任务及时放弃锁时，用 lockInterruptibly()；捕获 InterruptedException 后恢复中断标记，并把“尚未取得锁”和“已取得锁后失败”分开处理。

先把“卡在锁外”与“业务执行中”分开

ReentrantLock.lock() 的语义是持续等待直到拿到锁；它不会因为线程被中断就自动抛出异常。lockInterruptibly() 则把等待过程设置为显式中断点：锁被别的线程占用时，当前线程可以在等待期间收到中断并抛出 InterruptedException。

这两个阶段不能混在一个 catch 里处理。尚未拿到锁时没有资源需要释放；拿到锁之后做库存预扣，若后续校验失败，则必须走业务回滚，而不是把“解锁”误当成“回滚”。

让取消信号停在正确的等待边界

下面的示例模拟一个订单任务：先等待 SKU 锁，再检查库存，最后写入订单状态。reserveStock 只有在 lockInterruptibly 返回后才会进入临界区。

private final ReentrantLock stockLock = new ReentrantLock();

public boolean reserveStock(String sku, int quantity) throws InterruptedException {
    stockLock.lockInterruptibly();
    try {
        int available = stockRepository.available(sku);
        if (available 

这里的调用链是 reserveStock → stockLock.lockInterruptibly → stockRepository.available → stockRepository.decrease。如果中断发生在锁等待阶段，后面的库存读取和扣减都不会执行，调用方可以把任务标记为取消。

InterruptedException 之后为什么还要恢复中断标记

Java 文档规定，等待期间被中断时，lockInterruptibly() 抛出 InterruptedException，同时清除当前线程的中断状态。若直接记录日志然后返回，线程池上层就看不到取消信号，后续代码可能继续领取新的任务。

public void runReservation(String sku, int quantity) {
    try {
        boolean reserved = reserveStock(sku, quantity);
        if (!reserved) {
            reservationEvents.publish("库存不足", sku);
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        reservationEvents.publish("任务取消", sku);
    }
}

runReservation 负责把异常翻译成业务事件，但不吞掉线程的中断语义。调用方可以依据 任务取消 做重试或补偿；注意这里不能把取消伪装成库存不足，因为两者的后续动作不同。

已取得锁后的失败必须有业务回滚

中断并不等于自动撤销数据库写入。假设 stockRepository.decrease 已经成功，而 orderRepository.markReserved 失败，单纯执行 unlock() 只会释放互斥锁，库存数量仍可能少了一份。

public boolean reserveWithRollback(String sku, int quantity)
        throws InterruptedException {
    stockLock.lockInterruptibly();
    boolean decreased = false;
    try {
        if (stockRepository.available(sku) 

生产代码还要把库存与订单放进同一事务或可靠补偿机制；这个示例只突出边界：decreased 表示临界区内已经改变了业务数据，stockLock.unlock 表示并发访问恢复，两者不是同一件事。

用三个信号验收取消与解锁

1. 让线程 A 持有 stockLock，线程 B 调用 reserveStock，确认 B 阻塞在 lockInterruptibly 而不是进入 available。
2. 中断线程 B，确认收到 InterruptedException，并检查 B 的 isInterrupted() 在恢复代码后为 true。
3. 释放线程 A 的锁，再运行一次正常订单，确认没有遗留锁，也没有把前一次取消误报为库存不足。

日志建议至少带上 SKU、订单号、线程名和事件值：等待锁、任务取消、库存不足、预扣回滚。只打印“线程中断”不够，排查时无法知道业务数据是否已经改变。

几个容易把取消语义写坏的细节

• 不要在 catch (InterruptedException) 中什么都不做；吞掉中断会让上层调度器失去停止依据。
• 不要无条件执行 unlock()；只有确认当前线程成功取得锁，才允许释放。
• 不要把超时、库存不足、线程取消都映射成同一个状态；它们对应不同的重试和补偿策略。
• 公平锁只能影响排队顺序，不能代替取消设计；需要超时边界时，应评估 tryLock 的定时版本。

相关问题

lockInterruptibly() 会在锁空闲时抛出异常吗？

如果线程进入方法前已经处于中断状态，仍可能直接抛出；如果锁空闲且没有中断，它会立即取得锁。

捕获 InterruptedException 后一定要重新抛出吗？

不一定。若当前方法不能继续声明异常，可以转换成业务取消事件，但应恢复中断标记，让更上层仍能观察到取消。

unlock() 能回滚库存吗？

不能。unlock() 只改变锁的持有状态，库存回滚需要事务、补偿动作或其他一致性方案。

小结

可中断锁解决的是“线程如何离开等待队列”，不是“业务如何自动回到原点”。把 lockInterruptibly、中断标记恢复、临界区数据变化和回滚验收分别记录，取消任务才不会变成一条无法解释的半成功链路。