如何通过 ReentrantReadWriteLock 的锁升降级语义分析其在处理“读多写少且需强一致性”场景下的优势

ReentrantReadWriteLock 的锁降级，是在“读多写少且需要强一致性”这个特定场景下，真正经得起推敲的唯一技术路径。至于锁升级，也就是从读锁试图获取写锁，这条路根本走不通——强行走，要么线程卡死，要么直接抛异常。我们先说结论。

那么，锁降级为什么能保证强一致性？这得从需求说起。所谓强一致性，简单讲就是：数据一写进去，后面的读操作立刻能看到，中间不能被任何其他写操作给搅和了。如果用 synchronized 或者 ReentrantLock 把读写都串行化，吞吐量会断崖式下跌。而 ReentrantReadWriteLock 的降级机制，恰恰让“写后即读”这个高频操作变成了带有原子性保障的动作。仔细拆解一下它的运作逻辑：当写锁被持有时，其他线程根本无法获取任何读锁或写锁，数据修改过程是绝对隔离的。当前线程在不释放写锁的前提下，成功拿到读锁——此刻 AQS 的 state 中，高16位（读锁计数）和低16位（写锁计数）同时非零，这是底层特意设计允许的一种特例。接下来释放写锁，但读锁仍然持有，此时其他线程可以并发读取，并且它们读到的必定是最新值。为什么？因为 JMM 中写锁的 release 操作和读锁的 acquire 操作之间，天然构成了 happens-before 关系。

至于锁升级为什么绝对不能做，这不是什么“不推荐”或者“谨慎使用”的提醒，而是 JVM 层面就从根子上封死了这条路。一旦某个线程先持有了读锁，再去调用 writeLock.lock()，结果只有两种可能：在非公平模式下，大概率陷入无限等待——因为写锁获取的前提是确保没有任何读锁存在，包括当前线程自己的那个，而它自己正占着读锁不肯放。在公平模式下，同样会阻塞，甚至可能触发线程饥饿，因为等待队列里已经有其他线程在排队等写锁了。无论哪种模式，底层都不会帮你自动释放已有的读锁再去抢写锁——这不是设计的疏忽，而是刻意为之，为的就是避免死锁链，比如线程 A 占了读锁等着写锁，线程 B 也占了读锁等着写锁，两者互相僵持，谁也动不了。

聊到实际编码，锁降级有三个硬性条件，少一个都不行。不少人以为写个 readLock.lock() 就完事了，其实远没那么简单。第一，整个过程必须由同一个线程完成——从 writeLock.lock() 到 readLock.lock() 再到 writeLock.unlock()，三步缺一不可，且必须串行在同一个线程里。第二，获取读锁的动作必须发生在写锁释放之前，顺序不能搞反，否则降级逻辑就崩塌了。第三，写锁的重入次数必须为 1。这一点最容易踩坑：如果同一线程给写锁加了好几次锁，导致 exclusiveCount(state) > 1，这时候只调用一次 unlock，写锁实际上还没释放，虽然当前线程能拿到读锁，但写锁并没有真正放开，其他线程仍然无法写入——这是个很隐蔽的问题。

降级完成之后，还有一个细节特别容易被忽略，那就是读锁的生命周期管理。很多人只记得写锁要 release，却忘了降级后拿到的那个 readLock 是独立的锁对象，必须显式调用 unlock()，否则就会造成锁泄漏。看一段代码就清楚了：

writeLock.lock();
try {
    updateData();
    readLock.lock(); // ✅ 获取读锁
} finally {
    writeLock.unlock(); // ✅ 释放写锁
}
try {
    useUpdatedData(); // ✅ 此时受读锁保护
} finally {
    readLock.unlock(); // ⚠️ 必须写！否则该线程下次再走降级流程会因读锁未释放而失败
}

更隐蔽的问题在于：如果 useUpdatedData() 这个方法抛出异常，而你没有在 finally 块中释放读锁，那这把读锁就永远卡住了。这种情况比写锁泄漏更难排查，因为它不影响写入操作，只会悄悄地把读并发的性能一点点拖垮。