ReentrantReadWriteLock的锁降级本身不保障可见性，其作用是在持有写锁时安全获取读锁；真正的可见性由写锁释放时的内存屏障及后续读锁获取时的重新读取保证。
ReentrantReadWriteLock 的锁降级（write-to-read downgrade）本身不能直接保障数据变更后的可见性，它只是提供了一种在持有写锁的前提下安全获取读锁的机制；真正的可见性保障，依赖于写锁释放时的内存屏障（happens-before 语义）以及后续读锁获取时对共享变量的重新读取。锁降级的关键价值在于：避免写操作完成后、读操作开始前出现“中间态”被其他线程读到，同时让当前线程能继续以读锁方式安全访问刚更新的数据。
锁降级的正确写法与 happens-before 链
要使降级生效并保证可见性，必须严格遵循以下顺序：
- 先获取写锁（
writeLock.lock()） - 修改共享数据（如更新缓存、刷新状态等）
- 在不释放写锁的前提下获取读锁（
readLock.lock()） - 然后才释放写锁（
writeLock.unlock()）——此时 JVM 内存模型确保写操作对后续读操作可见 - 最后在使用完数据后释放读锁（
readLock.unlock()）
这个过程构成一条完整的 happens-before 链：写锁内的写操作 → 写锁释放 → 读锁获取 → 读锁内的读操作。正是这条链，使得当前线程降级后读到的数据一定是最新值，且其他线程在之后获取读锁时也能看到该更新。
为什么不能先释放写锁再加读锁？
如果写完后立即 writeLock.unlock()，再 readLock.lock()，就破坏了原子衔接：
- 写锁释放瞬间，其他线程可能抢先获取写锁并修改数据
- 当前线程再获取读锁时，读到的可能是别人改过的新值，也可能是旧值（取决于是否发生上下文切换或竞争），无法保证“自己刚写的值一定被自己读到”
- 更严重的是，JVM 不再能建立从该次写操作到后续读操作的 happens-before 关系，可见性失去保障
典型适用场景：缓存刷新 + 立即读取
常见于本地缓存（如 Guava Cache 不适用，但自研轻量缓存可用）中“先更新、再读取”的闭环逻辑：
- 缓存条目过期，需从 DB 重新加载 → 持有写锁加载新数据
- 加载完成后不希望释放锁让别人趁机写入，又需要以只读方式校验或封装结果 → 执行降级
- 降级后可安全调用
toString()、序列化、日志打印等只读操作，且确保看到的是刚刚写入的最新快照
注意：该模式不适用于需要长期持有读锁的场景（易导致写饥饿），仅适合“写完立刻读、读完马上放”的短临操作。
一个简明代码示例
private final ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock();
private volatile String data = "init";
public String updateAndGet() {
rwLock.writeLock().lock();
try {
// 1. 修改数据
data = fetchDataFromDB(); // 假设是耗时操作，但已受写锁保护
// 2. 在写锁未释放时获取读锁（降级起点）
rwLock.readLock().lock();
// 3. 立即释放写锁 —— 此刻 happens-before 生效
rwLock.writeLock().unlock();
// 4. 安全读取：一定能看到上面刚写的值
return data;
} finally {
// 5. 最终释放读锁（注意：若上面抛异常，需确保读锁也被释放）
rwLock.readLock().unlock();
}
}
⚠️ 注意：上述代码中 writeLock.unlock() 必须在 readLock.lock() 之后、且在 return 前执行；否则会死锁（因写锁未放，读锁无法被其他线程获取，而当前线程又占着写锁试图拿读锁——但 ReentrantReadWriteLock 允许降级，所以本线程可成功，但逻辑已错乱）。
