锁降级不能解决单线程内可见性问题，因同线程写后读天然可见；其真正用途是同一线程写后无缝转为读锁以阻断他线程写入，需在写锁释放前成功获取读锁并避免死锁与泄漏。
锁降级不能直接解决单线程内的可见性问题——它根本不是为这个设计的；单线程内写后读天然可见，无需锁介入。真正需要锁降级的场景，是「当前线程写完后，要继续以读锁身份长期持有访问权，同时确保其他线程无法在此间隙篡改数据」。混淆这一点，极易写出有竞态漏洞的代码。
为什么单线程内“先写后读”不需要锁降级
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(); // 别忘释放
}
比锁降级更轻量、更安全的替代方案
多数所谓「需要降级」的需求，其实只是没分清边界：
- 单次写 + 后续只读访问（无并发写需求）→ 直接用
volatile字段 +synchronized写块，读完全无锁 - 读多写少 + 需要乐观一致性 →
StampedLock的tryOptimisticRead()+ 验证模式，性能更好、无锁升级/降级陷阱 - 仅需保证写入对所有线程立即可见 →
volatile+ 最小化临界区，比ReentrantReadWriteLock简洁可靠得多
真正难的从来不是写出降级代码，而是冷静判断：此刻是否真的需要让一个线程在写锁和读锁之间做原子交接？大多数时候，答案是否定的。
