怎么通过 ReentrantReadWriteLock 的锁降级特性解决在单线程内先写后读的数据可见性问题-java教程-PHP中文网

锁降级不能解决单线程内可见性问题，因同线程写后读天然可见；其真正用途是同一线程写后无缝转为读锁以阻断他线程写入，需在写锁释放前成功获取读锁并避免死锁与泄漏。

怎么通过 reentrantreadwritelock 的锁降级特性解决在单线程内先写后读的数据可见性问题

锁降级不能直接解决单线程内的可见性问题——它根本不是为这个设计的；单线程内写后读天然可见，无需锁介入。真正需要锁降级的场景，是「当前线程写完后，要继续以读锁身份长期持有访问权，同时确保其他线程无法在此间隙篡改数据」。混淆这一点，极易写出有竞态漏洞的代码。

为什么单线程内“先写后读”不需要锁降级

Java 内存模型规定：同一个线程内，按程序顺序执行的写操作对后续读操作天然可见（as-if-serial 语义）。只要没有跨线程共享、没有重排序干扰（比如字段非 volatile 且无同步块），data = 42; return data; 这种写后立即读，永远返回 42。加 ReentrantReadWriteLock 反而引入不必要开销和死锁风险。

真正该用锁降级的典型场景

常见于配置热更新、缓存预热等「一次写 + 多次只读访问」且要求强一致性的流程。核心诉求是：写完后，本线程必须能安全地持续读，同时阻断其他线程的写入，直到自己读完。

必须由**同一个线程**完成：获取写锁 → 修改数据 → 获取读锁 → 释放写锁 → 继续读操作
读锁获取必须在写锁释放前完成，否则出现「防御真空期」：其他线程可能在 writeLock.unlock() 后、readLock.lock() 前抢到写锁并修改数据
必须用 readLock.tryLock() 而非 readLock.lock()：已持写锁时调用 lock() 可能因读锁计数饱和而自阻塞，导致死锁
写锁释放后，读锁仍需显式 unlock()，否则造成锁泄漏——这点常被忽略

正确降级的最小可行代码结构

writeLock.lock();
try {
    updateSharedData(); // 修改共享状态
    if (!readLock.tryLock()) {
        throw new IllegalStateException("Read lock acquisition failed during downgrade");
    }
} finally {
    writeLock.unlock(); // 关键：必须在此处释放写锁，此时读锁已稳住
}
// 此时只有读锁生效，可安全执行耗时读操作
try {
    return readCachedData();
} finally {
    readLock.unlock(); // 别忘释放
}