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

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

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

写锁降级到底改变了什么

这里的“降级”描述的是权限变化，不是锁对象替换。线程先通过 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 接住后续读取。示例方法在返回前释放读锁；如果调用方需要在同一临界区继续读取，应把读取动作放在降级之后，而不是把读锁提前到刷新之前。

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

假设顺序写成“释放 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 分散到多个不相干的回调中，否则很难确认异常发生时谁仍然拥有锁。

迁移旧代码时先改顺序，再补验证

如果旧代码已经在写锁释放后才申请读锁，迁移时先只调整锁顺序，不要同时替换缓存容器或加入新的线程池。最小改动更容易判断问题来自锁边界还是数据结构。

1. 确认共享数据的刷新动作全部位于 WriteLock 临界区。
2. 确认 ReadLock.lock() 位于 WriteLock.unlock() 之前。
3. 确认每个成功获取的锁都在 finally 中释放，且读锁释放先于写锁释放。
4. 用一个刷新线程和多个读取线程重复运行，检查读取结果只来自旧完整快照或新完整快照。

验证时可以给 refreshCache 注入一次明确的异常，让测试确认写锁仍会释放；再在读路径增加短暂阻塞，观察降级成功后其他读线程是否能够并发进入。不要只看“没有死锁”，还要核对缓存内容是否出现缺字段或混合版本。

相关问题

读锁能不能直接升级成写锁？

不建议把它当成普通的对称操作。持有读锁时申请写锁可能互相等待，通常应释放读锁后重新申请写锁，并重新读取需要修改的状态。

降级后什么时候释放读锁？

由最后一段需要一致读取的代码决定。只要仍需保护共享缓存，就保持读锁；读取结束后在 finally 中释放，不要依赖线程结束自动清理。

最小验证清单

• 能在代码中找到 WriteLock、refreshCache、ReadLock 的先后关系。
• 写锁释放前已经成功获取读锁。
• 异常时 finally 仍会释放已获取的锁。
• 测试结果不会出现半刷新缓存，也没有因锁升级形成等待环。