当前位置：首页 > 文章列表 > 文章 > java教程 > Java ReentrantReadWriteLock 如何安全降级写锁：读锁接管、异常路径与释放顺序

Java ReentrantReadWriteLock 如何安全降级写锁：读锁接管、异常路径与释放顺序

来源：17golang原创 2026-08-30 00:07:50 0浏览收藏

缓存刷新时，线程往往需要先独占地重建数据，再让其他读线程继续读取同一份结果。Java 的 ReentrantReadWriteLock 可以把这个过程拆成写锁独占和读锁共享两段，但“先拿读锁、再放写锁”的顺序不能颠倒，否则写锁一释放，另一个线程就可能看到半成品。

安全的锁降级顺序是：持有写锁完成刷新，先获取读锁，再释放写锁；异常路径则用 finally 按相反顺序释放已经成功获取的锁。

实践要点

写锁负责刷新共享缓存，读锁负责保护刷新后的读取。
降级不是“写锁变成读锁”，而是同一线程先持有两把锁，再释放写锁。
每个 lock 都要和对应的 unlock 配对，尤其要区分读锁是否真的获取成功。

写锁降级到底改变了什么

这里的“降级”描述的是权限变化，不是锁对象替换。线程先通过 WriteLock 排除其他读写线程，调用 refreshCache 把共享缓存更新完整；随后取得 ReadLock，最后才释放 WriteLock。这样，降级后的线程继续持有读权限，其他读线程也可以进入，而不会在写锁释放和读锁获取之间插入一次读取。

private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
private final Lock WriteLock = lock.writeLock();
private final Lock ReadLock = lock.readLock();
private final Map cache = new HashMap();

public String get(String key) {
    ReadLock.lock();
    try {
        return cache.get(key);
    } finally {
        ReadLock.unlock();
    }
}

public void refreshCache(Map incoming) {
    WriteLock.lock();
    boolean readLocked = false;
    try {
        cache.clear();
        cache.putAll(incoming);
        ReadLock.lock();
        readLocked = true;
    } finally {
        if (readLocked) {
            ReadLock.unlock();
        }
        WriteLock.unlock();
    }
}

这段代码展示的是完整的调用链：WriteLock 进入独占区，refreshCache 完成数据替换，ReadLock 接住后续读取。示例方法在返回前释放读锁；如果调用方需要在同一临界区继续读取，应把读取动作放在降级之后，而不是把读锁提前到刷新之前。

Java ReentrantReadWriteLock 中 WriteLock、refreshCache、ReadLock 与 unlock 的降级调用链

为什么必须先拿读锁再放写锁

假设顺序写成“释放 WriteLock，再获取 ReadLock”。这两个动作之间存在空档：等待中的写线程可能抢到写锁，也可能读线程直接读到旧缓存；更糟糕的是，如果刷新代码把引用切换和内容填充分成了多个动作，别的线程可能观察到中间状态。

正确的关键不在于让线程永远持有写锁，而在于把“接管读取权限”放在写锁仍然有效的时刻。ReadLock.lock() 成功后，当前线程同时持有写锁和读锁；此时释放 WriteLock 不会让它失去读权限，其他读线程也能安全加入。

不要把锁升级当成对称操作

从读锁直接申请写锁属于锁升级，通常会造成等待环：当前线程持有读锁，写锁又要等所有读锁退出，而当前线程自己无法退出读锁。需要修改数据时，应先结束读锁临界区，再重新竞争写锁；本文讨论的写转读降级与此相反。

异常路径要看清每一把锁的状态

ReadLock.lock() 之后可能继续执行，也可能在更复杂的封装代码里因为上游异常而没有走到成功标记。用 readLocked 记录状态，可以避免在读锁没有成功获取时误调用 ReadLock.unlock()。同时，WriteLock.unlock() 必须放在外层 finally 中，保证刷新阶段抛出异常时仍能释放写锁。

WriteLock.lock();
boolean readLocked = false;
try {
    refreshCache(incoming);
    ReadLock.lock();
    readLocked = true;
} finally {
    if (readLocked) {
        ReadLock.unlock();
    }
    WriteLock.unlock();
}

这里的释放顺序是获取顺序的逆序：先释放后来获取的 ReadLock，再释放先获取的 WriteLock。不要在 refreshCache 内部偷偷释放写锁，也不要把同一把锁的 unlock 分散到多个不相干的回调中，否则很难确认异常发生时谁仍然拥有锁。