ReentrantReadWriteLock的锁降级是读多写少且需强一致性的唯一可靠路径；锁升级不可行，会阻塞或抛异常。降级通过写锁未释放时获取读锁、再释放写锁实现强一致性，但须同线程、写锁重入数为1、显式释放读锁。
ReentrantReadWriteLock 的锁降级是它在“读多写少且需强一致性”场景下真正可用的唯一可靠路径；锁升级（读→写）根本不可行，强行尝试会卡死或抛异常。
为什么锁降级能保证强一致性
强一致性要求：写入后立即被后续读操作看到，且中间不能被其他写操作干扰。单纯用 synchronized 或 ReentrantLock 会导致读操作串行化，吞吐暴跌；而 ReentrantReadWriteLock 的降级机制让「写后即读」这个高频模式变成原子性保障动作：
- 写锁持有期间，其他线程无法获取任何读/写锁 → 数据修改过程完全隔离
- 当前线程在不释放写锁的前提下，成功获取读锁 → state 中高16位（读锁计数）+低16位（写锁计数）同时非零，这是 AQS 允许的特例
- 随后释放写锁，但读锁仍持有 → 其他线程可并发读，且能看到刚写入的最新值（因 JMM 中写锁 release 与读锁 acquire 构成 happens-before）
锁升级（readLock → writeLock）为什么绝对不能做
这不是“不推荐”，而是 JVM 层面直接禁止的行为。一旦线程先持有了 readLock，再调用 writeLock.lock()，结果只有两种：
- 在非公平模式下：大概率无限等待 —— 因为写锁获取前必须确保无任何读锁（包括当前线程自己的），而它自己正占着读锁
- 在公平模式下：同样阻塞，且可能触发线程饥饿，因为队列中已有其他线程在等写锁
- 无论哪种模式，都不会自动释放已有读锁去抢写锁 —— 这不是设计缺陷，是刻意为之，避免死锁链（比如 A 持读等写，B 持读等写，互相僵持）
实际编码中锁降级的三个硬性条件
降级不是写个 readLock.lock() 就完事，必须满足以下全部条件，否则会阻塞甚至逻辑错误：
- 必须由同一个线程执行：
writeLock.lock()、readLock.lock()、writeLock.unlock()三步都在同一线程内完成 - 必须在写锁未释放前获取读锁：顺序不能颠倒，
readLock.lock()必须出现在writeLock.unlock()之前，否则降级失败 - 写锁重入次数必须为 1：如果写锁被同一线程重复加锁多次（
exclusiveCount(state) > 1），只 unlock 一次会导致写锁仍持有，此时读锁虽能拿到，但写锁没真正释放，后续其他线程仍无法写入 —— 这容易被忽略
降级后读锁的生命周期管理容易漏掉
很多人只记得「写锁要 unlock」，却忘了降级后的 readLock 是独立锁对象，必须显式 unlock()，否则造成锁泄漏：
writeLock.lock();
try {
updateData();
readLock.lock(); // ✅ 获取读锁
} finally {
writeLock.unlock(); // ✅ 释放写锁
}
try {
useUpdatedData(); // ✅ 此时受读锁保护
} finally {
readLock.unlock(); // ⚠️ 必须写！否则该线程下次再走降级流程会因读锁未释放而失败
}
更隐蔽的问题是：如果 useUpdatedData() 抛异常且未在 finally 块中 unlock，读锁就永远卡住 —— 这比写锁泄漏更难排查，因为不影响写，只悄悄拖垮读并发能力。
