ReentrantReadWriteLock的锁降级是唯一安全的写后即读路径，仅允许同一线程按writeLock→readLock→unlock(writeLock)顺序执行，确保写后立即读的一致性，而非提升读并发。
ReentrantReadWriteLock 的锁降级不是为了“提升读并发”，而是**唯一安全的写后即读路径**——它只允许「先持写锁 → 再获取读锁 → 最后释放写锁」这一固定顺序，且必须由**同一个线程**完成。想靠它“最大化读并发”是方向性误解；真正提升读并发靠的是**尽早释放写锁、让读锁尽快接管**。
锁降级的唯一合法流程：writeLock → readLock → unlock(writeLock)
这是 ReentrantReadWriteLock 唯一允许的降级方式，其他任何组合都会阻塞或抛异常：
- 写锁未持有时直接调
readLock.lock()：正常，但和降级无关 - 已持读锁再调
writeLock.lock()：必然死锁（读写不可重入） - 两个线程分别持读锁和写锁：写锁会等所有读锁释放，读锁会等写锁释放 → 互斥生效
- 写锁释放后才加读锁：不算降级，只是普通读操作，不保证中间无修改
关键点在于：降级过程中，写锁必须**一直持有**，直到读锁成功获取后，才能释放写锁。否则数据可能被其他写线程篡改。
为什么不能“先释放写锁再加读锁”
看似省事，实则破坏强一致性：
- 写操作完成后，若立即
writeLock.unlock()，其他写线程可能瞬间抢占并修改数据 - 此时你再
readLock.lock()，拿到的是别人刚写的新值，而非你刚写完的那版 - 你本意是“我写了，然后立刻读自己写的”，结果变成“我写了，别人抢着改了，我读到别人的”
降级正是为堵住这个窗口：JVM 保证在同一线程内，readLock.lock() 成功返回前，writeLock 仍有效，其他写线程无法插入。
正确降级的最小安全模板
writeLock.lock();
try {
// 修改共享状态
data.update(...);
// 关键：在此处获取读锁（必须成功，否则降级失败）
readLock.lock(); // 注意：这步可能阻塞，但不会死锁（因当前线程已持写锁）
// 立即释放写锁，读锁继续持有
writeLock.unlock(); // 必须在 readLock.lock() 成功后、且仍在 try 块内
// 此刻：只有读锁生效，其他读线程可并发进入
return data.snapshot(); // 安全返回你刚写完的状态
} finally {
// 只释放读锁，不碰写锁（它已在上面 unlock 了）
if (readLock.isHeldByCurrentThread()) {
readLock.unlock();
}
}
漏掉 writeLock.unlock() 会导致写锁长期占用，读并发上不去；提前 unlock 则失去一致性保障。这两步顺序和位置不能错。
容易被忽略的三个硬约束
实际编码中，以下三点常被跳过，导致降级失效或性能反降：
-
readLock和writeLock必须来自同一个ReentrantReadWriteLock实例，跨实例降级无效 - 整个流程必须在**单线程内完成**，不能把写锁传给另一个线程去降级
-
readLock.lock()是阻塞调用，若此时有其他线程正持有读锁（比如长耗时读操作），它会等——这不是 bug，是设计使然；若不能接受等待，说明场景不适合用降级，该换StampedLock的乐观读
降级本身不提速，它只保“写后即读”的原子性；真正的读并发提升，取决于你能否快速走完写→降级→释放写锁这个链路，并让后续读操作尽量走纯读锁路径。
