当前位置：首页 > 文章列表 > 文章 > java教程 > Java ReentrantLock 的 lockInterruptibly 怎么处理中断：等待队列与释放顺序

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

来源：17golang原创 2026-08-28 04:53:35 0浏览收藏

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

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

要点速览

lockInterruptibly() 只改变当前线程的等待行为，不会抢走别的线程持有的锁。
入口已经是中断状态，或排队期间收到中断，都会抛出 InterruptedException，并清除中断状态。
拿锁成功后必须用 try/finally 配对 unlock()；异常路径不能漏掉释放。

lockInterruptibly 解决的是哪一种等待

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

调用	锁被占用时	调用方要处理什么
`lock()`	继续等待	没有受检异常分支
`lockInterruptibly()`	等待或响应中断	捕获 `InterruptedException`
`tryLock(timeout, unit)`	等待到超时或中断	区分 false 与异常

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

关键是让 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();
    }
}

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

Java ReentrantLock lockInterruptibly InterruptedException 锁竞争调用链

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

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

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

Java InterruptedException finally unlock 锁状态变化与释放顺序

三个边界别混在一起

入口前已经中断

线程带着中断状态进入 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 释放”两条路径。