锁降级只允许写锁→读锁，不支持读锁→写锁，因防死锁而设计；需同一线程先获写锁、再获读锁、最后释放写锁，三步缺一不可，否则导致锁异常或数据不一致。
锁降级只允许写锁 → 读锁，不能反过来
Java 中的 ReentrantReadWriteLock 支持锁降级（write-to-read），但**不支持锁升级（read-to-write）**——这是硬性限制，不是实现缺陷，而是为避免死锁刻意设计的。一旦线程持有读锁，再尝试获取写锁会永远阻塞（除非自己先释放读锁，但此时已失去原子性保障）。
- 常见错误现象：
Thread A持有读锁后调用writeLock().lock()，结果卡住，CPU 不涨、日志不报错，只表现为业务超时或线程堆积 - 正确前提：必须是**同一个线程**，先成功获取
writeLock()，再获取readLock()，最后释放writeLock() - 为什么这样设计？防止“读-写”升级时出现循环等待：A 持读锁等 B 的写锁，B 持写锁等 A 的读锁释放 → 死锁
写锁降级为读锁的三步实操流程
降级不是自动发生的，必须显式按顺序执行，漏掉任意一步都会导致锁状态异常（比如写锁释放后变成无锁，而非读锁）。
- 第一步：获取写锁 →
writeLock.lock() - 第二步：在写锁未释放前，获取读锁 →
readLock.lock()（注意：这是重入，不会阻塞） - 第三步：释放写锁 →
writeLock.unlock()（此时线程仍持有读锁，即完成降级） - ⚠️ 容易踩的坑：在第三步之前没调用
readLock.lock()，或调用后又误调了readLock.unlock()，会导致降级失败，线程直接退出临界区
为什么需要锁降级？不是多此一举吗
核心价值在于「数据一致性 + 并发读性能」兼顾。典型场景：缓存更新。你修改完数据（需写锁），但后续大量请求要读它（希望允许多个线程并发读），这时立刻释放全部锁太激进，而一直占着写锁又扼杀并发。
- 使用场景举例：本地缓存
Map更新后，让其他线程能立即安全读取新值，而不是等你整个操作结束 - 性能影响：降级后，其他线程可立即获取读锁，吞吐量显著高于全程持写锁；但要注意——读锁仍会阻塞后续写锁请求，所以降级不是“放行一切”，只是切换成更宽松的同步策略
- 参数差异：无需额外配置，
ReentrantReadWriteLock默认就支持降级；但若构造时传了true（公平模式），降级后新来的读线程可能被排队，反而削弱并发优势
降级后读锁怎么安全释放
降级完成≠万事大吉。读锁仍需手动释放，且释放时机决定并发行为是否符合预期。
- 必须由**同一线程**调用
readLock.unlock()，否则抛IllegalMonitorStateException - 常见错误：在 finally 块里只释放了写锁，忘了读锁 → 导致读锁永久泄漏，最终所有写操作被阻塞
- 建议写法：用嵌套 try-finally 或统一出口管理，例如：
readLock.lock(); try { // 读操作 } finally { readLock.unlock(); // 必须配对 } - 注意：降级后的读锁和普通读锁行为完全一致，不保留“曾是写锁”的任何特殊语义
