锁降级是线程在持有写锁后、释放前获取读锁，再释放写锁，以原子化完成“写→读”切换并保证跨线程数据一致性；必须严格按“获取写锁→获取读锁→释放写锁”三步执行，否则引发竞态或数据不一致。

锁降级不是让读操作“看到自己刚写的值”，而是确保：当前线程写完后，能**无缝切换为读锁持有者**，从而阻止其他线程在此间隙篡改数据，并让后续读取基于最新状态——可见性靠的是写锁释放的 happens-before 语义，而非降级动作本身。

必须严格遵循的三步顺序

降级成功与否，只取决于代码执行的时序是否精准，缺一不可：

• 先获取写锁：调用 writeLock.lock()，独占临界区，完成所有修改逻辑
• 在写锁未释放前获取读锁：调用 readLock.lock()（此时因已持写锁，该操作不会阻塞，属于重入）
• 紧接着释放写锁：调用 writeLock.unlock()，这一步触发内存屏障，使之前所有写操作对其他线程可见

此时线程仅持有读锁，其他线程可并发获取读锁，但无法获取写锁——临界区从“独占写”平滑过渡到“共享读”。

为什么不能先释放写锁再加读锁

看似只是两行代码调换顺序，实则引入严重竞态窗口：

• 写锁一释放，其他线程可能立即抢到写锁并修改数据
• 本线程随后才去获取读锁，读到的已是别人改过的新值，甚至可能是中间态或无效值
• 更糟的是：它自以为在读“自己刚写的数据”，实际完全失去一致性保障

这个间隙就是所谓的“防御真空期”，锁降级正是为了彻底消除它。

常见误操作与后果

实践中多数问题源于对流程理解偏差或疏忽：

• 忘记在 writeLock.unlock() 前调用 readLock.lock() → 直接退成无锁状态，数据裸奔
• 在 finally 块中重复释放写锁（比如降级时 unlock 一次，外层 finally 又 unlock 一次）→ IllegalMonitorStateException
• 降级后忘了 readLock.unlock() → 读锁永久泄漏，后续所有写操作被无限阻塞
• 在写锁持有期间调用另一个需写锁的方法 → 可能死锁，尤其当目标方法也尝试降级时

它不解决单线程可见性，也不等于锁升级

需要明确两个边界：

• 同一线程内，data = 42; return data; 天然可见，加锁纯属冗余；锁降级针对的是**跨线程的数据同步契约**
• 读锁永远不能升级为写锁。若已持读锁，再调 writeLock.lock() 会永久阻塞——这是 ReentrantReadWriteLock 的主动设计，为防死锁

任何“先读再决定是否写”的逻辑，都应放弃降级幻想，直接用写锁兜底判断和操作。