reentrantreadwritelock 不支持读锁升级为写锁，因其会导致死锁、破坏共享语义且无法保障可见性；降级可行因满足内存屏障与happens-before关系；替代方案应使用trylock或重构逻辑。
ReentrantReadWriteLock 不支持读锁升级为写锁，不是实现缺陷，而是基于并发安全与语义一致性的强制设计。核心原因有三点：死锁必然性、共享语义破坏、可见性无法保障。
死锁是确定性行为，不是偶发问题
当线程已持有读锁，再调用 writeLock().lock() 时，AQS 状态校验会立即拒绝该请求——它检测到当前线程已持读锁，直接返回 false，并将线程加入等待队列 park。此时读锁未释放，写锁又拿不到；其他线程也无法获取写锁（因读锁存在），甚至后续读操作也会被阻塞（写锁排队优先级高于新读锁）。单一线程“半占”资源，全局卡死。
- 线程 dump 中显示为 WAITING (parking)，但实际卡在写锁获取入口，而非读锁释放环节
- 哪怕只有两个线程同时走“读→升写”路径，也会相互等待对方释放读锁，形成循环等待
- 这种死锁不依赖超时或竞争强度，只要逻辑存在，高并发下必现
升级会破坏读锁的共享前提
读锁允许多线程并发进入临界区，本质是“只读承诺”。若允许某一线程在读过程中悄悄升级为写锁，等于在不通知其他读者的情况下单方面打破契约：
- 其他仍在读的线程，可能继续看到旧数据，或读到写入中途的脏状态
- 写操作的原子性边界失效：升级后写入，对其他线程不可见，直到该线程释放读锁——而释放时机完全不可控
- 语义混乱：一个本应“无副作用”的读操作，突然具备了修改能力，违背读写分离的设计初衷
降级可行，是因为它满足严格顺序与内存可见性
写锁 → 读锁降级被允许，且必须按三步执行：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 先独占获取写锁（确保修改权）
- 在未释放写锁前，立即获取读锁（同一线程重入成功，不阻塞）
- 再释放写锁（触发内存屏障，使写操作对其他线程可见）
这个过程天然保证了 happens-before 关系：写锁释放动作先行发生于后续其他线程获取读锁的动作。而读锁升级没有对应的同步契约，无法建立任何可靠的数据发布机制。
替代方案不是绕过限制，而是重构逻辑
业务中常见的“查缓存→miss→更新”场景，不能靠升级解决，正确做法是放弃读锁前置：
- 优先尝试 writeLock.tryLock()：抢到就双检写入；失败则退避或 fallback，不阻塞
- 若必须读优先，改用 readLock.tryLock() 非阻塞获取；失败立即重试，绝不 lock()
- 复杂流程中混入异常、超时、回调时，tryLock 的失败路径更易覆盖，比硬等 lock() 更可控
锁降级不是为了省一次锁开销，而是为写后立即读提供连续保护；读锁升级则没有任何合理使用场景——它既不安全，也不必要。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
