锁降级正确写法是先获取写锁、再获取读锁、最后释放写锁；它不是读锁变写锁，而是写线程修改后以读锁延续临界区，确保写后读的原子性与可见性。
锁降级的正确写法：必须先持写锁，再加读锁，最后释放写锁
锁降级不是“把读锁变成写锁”，而是写线程在完成修改后，不直接释放全部锁，而是先获取读锁、再释放写锁，从而以读锁身份继续访问数据。关键顺序不能错：writeLock.lock() → readLock.lock() → writeLock.unlock()。漏掉任意一步，或调换顺序（比如先 unlock 再 lock 读锁），都会导致其他线程看到中间态或触发阻塞。
常见错误现象包括：
- 写操作刚完成，其他线程就读到 null 或旧值（没加读锁就释放写锁）
- 当前线程卡在
readLock.lock()不返回（已在写锁中，但读锁被其他读线程占满且未释放，实际极少发生；更可能是自己忘了 unlock 读锁导致后续死锁） - 降级后仍调用
writeLock.unlock()两次（一次在降级时，一次在 finally 块里重复执行）
为什么必须用锁降级而不是直接用读锁 + 写锁分段？
单纯“先读再写”或“写完再读”无法保证可见性：写操作提交后、读操作开始前，可能有其他线程插入写入，导致本线程读到过期数据。锁降级通过持有读锁延续了临界区，让写后读成为原子连续过程。
典型适用场景是缓存更新后立即读取校验或构建视图，例如：
- 更新本地配置后，马上读取新配置生成生效对象
- 刷新数据库快照后，立刻读取该快照做一致性校验
- 构建不可变对象时，先写字段、再读全部字段封装为 final 实例
注意：降级只对**当前线程**有效，其他线程仍需正常获取读锁才能访问，不会破坏并发读能力。
锁降级不等于锁升级，读锁永远不能转成写锁
ReentrantReadWriteLock 明确禁止从读锁升级为写锁。如果一个线程已持有 readLock，再调用 writeLock.lock()，会一直阻塞——因为写锁要求所有读锁释放，而它自己又握着一个读锁不放，形成自等待。
这种设计不是疏漏，而是刻意为之：
- 多个线程同时持读锁并尝试升级，必然死锁（A 等 B 放读锁，B 等 A 放读锁）
- 读锁共享语义会被破坏：一旦允许升级，读锁就不再是“可并发持有”的安全前提
- 可见性无法保障：某线程升级成功写入，其他仍持旧读锁的线程看不到变更
所以，任何“先读再决定是否写”的逻辑，必须放弃降级幻想，改用写锁兜底（即一开始就不拿读锁，直接上写锁判断+操作）。
公平性与性能影响：非公平模式更适合锁降级高频场景
ReentrantReadWriteLock 默认构造是 new ReentrantReadWriteLock(false)，即非公平模式。这对锁降级很关键：若用公平模式，写线程在降级时获取读锁可能被排在队尾，等前面所有等待者出队，反而失去降级意义。
实测中，非公平模式下锁降级延迟通常在纳秒级；公平模式下，尤其在高并发读压力下，readLock.lock() 可能延迟毫秒级甚至更久。
不过要注意：非公平不等于“不保序”，它只是不严格 FIFO，但仍保证写锁绝对优先于读锁（即写请求到达时，即使已有读锁在排队，新写锁仍可插队抢占），这对降级过程中的写→读衔接更友好。
真正容易被忽略的是降级后的读锁生命周期管理：它和普通读锁一样需要 unlock()，但很多人只记得写锁要释放，却在 finally 块里漏掉读锁的 cleanup，导致线程泄漏式持锁，最终拖垮整个读并发能力。
