Java ReentrantLock 的 lockInterruptibly 怎么处理中断：等待队列与释放顺序

线程在等待一把被占用的 ReentrantLock 时，如果业务已经取消，继续排队通常只会拖慢请求回收。Java 的 lockInterruptibly() 允许等待者响应中断：拿到锁就继续，等待期间被中断则抛出 InterruptedException，调用方可以立刻走取消或清理分支。

把中断当作“放弃本次获取锁的请求”，而不是“替别人释放锁”；只有成功获取锁的线程，才负责在 finally 中调用 unlock()。

lockInterruptibly 解决的是哪一种等待

ReentrantLock.lock() 会等待到锁可用；lockInterruptibly() 则把“线程被取消”纳入等待条件。它仍然只允许一个线程取得互斥锁，也仍然支持当前线程重入，但等待线程可以在锁长期被占用时退出。

最小写法：成功拿锁与中断分开处理

关键是让 unlock() 只出现在成功获取锁之后。下面的 refreshCache 不在 catch 中释放锁，因为抛出异常时它根本没有持有这把锁。

private final ReentrantLock lock = new ReentrantLock();

void refreshCache() {
    try {
        lock.lockInterruptibly();
        try {
            rebuildLocalCache();
        } finally {
            lock.unlock();
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        recordCancelledRefresh();
    }
}

这里的两层结构很实用：外层处理“没有拿到锁”的中断，内层保证“已经拿到锁”的代码无论正常返回还是抛异常都会释放锁。

等待队列里发生中断时，状态如何变化

假设线程 A 已经持有 ReentrantLock，线程 B 调用 lockInterruptibly 后进入等待。此时中断 B，B 会从等待路径退出并得到 InterruptedException；A 的所有权不变，B 也不能直接执行 unlock。

需要注意一个容易误判的细节：InterruptedException 抛出时，B 的中断状态已经被清除。如果上层还要让更外层感知取消，应像示例那样再次执行 Thread.currentThread().interrupt()；如果异常已经被统一取消框架接管，也要明确约定由哪一层恢复状态。

三个边界别混在一起

入口前已经中断

线程带着中断状态进入 lockInterruptibly() 时，方法不会先获得锁再处理业务，而是直接抛出 InterruptedException。因此不要把“调用返回”当作“已经加锁”的证据。

已经持锁后再次调用

ReentrantLock 是可重入锁。当前线程已经持有它时，再次调用 lockInterruptibly() 会增加持有次数并返回；后续仍要执行同样次数的 unlock()，否则锁不会真正变为可用。

公平锁不是取消机制

new ReentrantLock(true) 只影响竞争下的授予顺序，不能替代中断处理。公平策略还可能带来吞吐成本，是否开启应由等待分布和业务目标决定。

一段可以直接运行的竞争示例

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.locks.ReentrantLock;

public class InterruptibleLockDemo {
    public static void main(String[] args) throws Exception {
        ReentrantLock lock = new ReentrantLock();
        CountDownLatch held = new CountDownLatch(1);

        Thread owner = new Thread(() -> {
            lock.lock();
            try {
                held.countDown();
                Thread.sleep(3000);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                lock.unlock();
            }
        }, "owner");

        Thread waiter = new Thread(() -> {
            try {
                lock.lockInterruptibly();
                try {
                    System.out.println("acquired");
                } finally {
                    lock.unlock();
                }
            } catch (InterruptedException e) {
                System.out.println("cancelled while waiting");
                Thread.currentThread().interrupt();
            }
        }, "waiter");

        owner.start();
        held.await();
        waiter.start();
        Thread.sleep(100);
        waiter.interrupt();
        waiter.join();
        owner.join();
    }
}

可见结果应为 cancelled while waiting。如果把 waiter.interrupt() 删除，等待者会在 owner 释放锁后打印 acquired。这两个结果分别验证了“中断退出等待”和“正常获取后 finally 释放”两条路径。

常见问题

中断线程会自动把锁解开吗？

不会。中断只影响被中断线程的等待或响应逻辑，锁仍由持有者负责释放。

catch InterruptedException 后为什么常常要恢复中断状态？

因为该异常会清除当前线程的中断状态。恢复后，上层循环、执行器或取消框架仍能观察到取消信号。

能不能在 finally 里无条件 unlock？

不能。若获取锁的调用抛出异常，当前线程没有持有锁，无条件 unlock() 可能产生 IllegalMonitorStateException；应把 finally 放在成功获取之后。

最后的检查清单

• 是否只在成功获取锁的范围内调用 unlock()？
• 是否区分了等待中断、业务异常和超时返回？
• catch 后的中断状态由哪一层恢复，是否有明确约定？
• 是否用测试覆盖入口已中断、竞争中断和正常释放三条路径？