锁降级本身不保证可见性，靠的是写锁释放的happens-before效应：必须严格按“持写锁→获读锁→释写锁→持读锁”四步执行，跳过任一环节或中途写入都会破坏同步；volatile+synchronized或StampedLock常是更优替代。
写锁降级本身不保证可见性，靠的是锁的内存语义和释放顺序
ReentrantReadWriteLock 的锁降级（即持有写锁后获取读锁、再释放写锁）常被误认为“自动刷新缓存”，其实它不额外插入内存屏障；可见性保障来自 writeLock.unlock() 的 happens-before 效应——该操作对后续 readLock.lock() 成功获取读锁的线程构成同步关系。关键不是“降级动作”，而是写锁释放与读锁获取之间的时序约束。
必须按严格顺序执行：写 → 读 → 写锁释放 → 读锁保持
降级要生效，代码结构必须满足以下四步不可拆分：
- 当前线程已独占持有
writeLock - 在未释放写锁前，调用
readLock.lock()并成功获取读锁（此时读锁计数+1，写锁仍持有） - 紧接着调用
writeLock.unlock()（这是关键点：释放写锁，触发写内存屏障，使之前所有修改对其他线程可见） - 继续保持
readLock持有状态，供后续只读访问
任何跳过第2步（比如先释放写锁再加读锁），或在第3步前做耗时操作，都会破坏同步契约，导致其他线程看到过期数据。
常见错误：在降级路径中修改共享变量或嵌套锁
降级只适用于“写完即读”的场景，一旦在 writeLock.unlock() 前引入新写入，或在读锁持有期间尝试重入写锁，就会触发死锁或可见性断裂：
- 在
writeLock持有期间调用另一个也需writeLock的方法 → 可能死锁（即使可重入，也可能因锁升级被拒绝） - 在
readLock已获取但writeLock尚未释放时，修改非 volatile 字段 → 其他线程通过读锁看到的仍是旧值（因为写尚未发布） - 用
tryLock()替代lock()获取读锁，且未校验返回值 → 降级失败却继续执行读逻辑，造成数据不一致
替代方案更简单可靠：用 volatile + synchronized 或 StampedLock
如果只是想让一次写入对后续读取立即可见，ReentrantReadWriteLock 的降级流程过于沉重且易错。多数场景下：
- 单次写+多次读 → 直接用
volatile字段 + 简单synchronized写块，读完全无锁 - 读多写少且需乐观读 →
StampedLock的tryOptimisticRead()+ 验证模式更轻量，避免锁竞争 - 需要精确控制读写并发粒度 → 才值得用
ReentrantReadWriteLock，但务必把降级逻辑封装成原子 helper 方法，杜绝手写顺序错误
真正难的不是写对降级代码，而是判断“是否真需要它”——很多所谓“必须降级”的需求，其实只是没理清 volatile 的适用边界或误判了读写比例。
