锁降级的核心目的是消除“写后读”的可见性间隙，确保线程修改数据后能安全读取自己写入的最新值；其标准流程为：先获取写锁→修改数据→立即获取读锁→再释放写锁。
锁降级不是为了“优化读并发”，而是为了解决写后立即读的可见性间隙问题；它本身不提升并发度，反而会短暂增加读锁持有时间。
锁降级的真实作用：堵住写后读的可见性漏洞
不使用锁降级时，典型危险序列是：writeLock.lock() → 修改数据 → writeLock.unlock() → 读取数据。中间这个释放写锁到获取读锁的间隙，其他线程可能插入一次写操作，导致当前线程读到“新写入但非自己写入”的脏数据。
锁降级强制把这段间隙消除：必须在 writeLock.unlock() 前调用 readLock.lock()，确保写锁释放瞬间，读锁已就位。JVM 内存屏障和 AQS 的 state 状态更新共同保证了该路径下的 happens-before 关系。
- 仅当写操作后**紧跟着本线程的读操作**（如缓存更新 + 立即返回新值）才需要锁降级
- 如果写完就释放、后续读是另一个请求或异步任务，锁降级不仅无用，还会延长读锁占用，阻塞其他写线程
- 锁降级成功后，当前线程仍持有读锁，其他读线程可并发进入——这点和普通读锁行为一致，不是“额外并发”
正确实现锁降级的三步不可省略
标准流程必须严格遵循顺序，任何一步错位都会导致死锁或可见性失效：
- 先调用
writeLock.lock()，不能跳过或延迟 - 在
try块内完成写操作后，**立即**调用readLock.lock()；注意：这里不能用tryLock()，必须阻塞等待，否则降级失败 -
writeLock.unlock()必须放在readLock.lock()之后、且在同一个try块的finally外层 —— 否则可能在readLock.lock()抛异常时，写锁未释放
错误示例：readLock.lock() 放在 writeLock.unlock() 之后，或两个 lock() 之间夹了非原子业务逻辑，都会破坏降级语义。
为什么不能用 synchronized 或 ReentrantLock 替代
synchronized 和 ReentrantLock 都无法表达“写完立刻读且不被干扰”的语义：它们释放锁后，没有任何机制能保证下一个读操作看到的是刚写入的值，除非配合 volatile 字段或显式内存屏障，但这又引入额外开销和复杂度。
ReentrantReadWriteLock 的锁降级是唯一由 JDK 原生支持、且经过 AQS 严格验证的方案。它的底层依赖 state 的高16位（读锁计数）和低16位（写锁重入数）分离设计，使得同一线程在持有写锁时，readLock.lock() 可绕过常规读锁竞争逻辑，直接成功——这是其他锁做不到的原子能力。
容易忽略的一点：锁降级只对**当前线程有效**。其他线程仍需按常规方式获取读锁，不会因为某线程降级而获得特殊权限。
性能与公平性权衡：非公平模式下写线程可能饿死
默认非公平模式虽吞吐高，但在读流量极大时，写线程可能长期抢不到锁。若业务要求写操作有确定响应时间（如实时配置推送），应启用公平模式：new ReentrantReadWriteLock(true)。
- 公平模式下，写线程在队列头部等待，避免无限插队
- 但代价是每次锁获取都要检查队列状态，读并发峰值下降约 10%～15%
- 不要在锁降级路径中混用公平/非公平判断逻辑——降级本身不改变锁的公平策略，只依赖当前实例初始化时的设定
真正难处理的从来不是代码怎么写，而是判断“这里到底需不需要降级”。多数场景其实只需要普通读写分离，强行加降级反而把简单问题搞复杂。
