ReentrantReadWriteLock 不支持锁升级是必然设计选择，因其基于AQS状态模型和读写互斥语义：读锁存在时写锁获取被主动拒绝，位域结构（高16位读锁、低16位写锁）天然隔离读写状态，且升级会引发活锁与语义歧义；而锁降级可行，因写锁独占前提下转为读锁符合单向状态收缩。
ReentrantReadWriteLock 不支持锁升级，不是实现疏漏，而是基于 AQS 状态模型和读写互斥语义的必然设计选择。
读锁存在时写锁获取被主动拒绝
当线程已持有读锁，再调用 writeLock().lock()，AQS 的 tryAcquire 会立即检查当前线程是否已持读锁。一旦确认，直接返回 false，不进入重试循环，也不尝试抢占——而是直接入队并 park。这不是“等读锁释放”，而是“拒绝申请”，因为读写共存违背锁的基本契约。
- 读锁是共享模式，允许多个线程同时持有；写锁是独占模式，要求排他性
- 若允许升级，等于允许“读+写”共存，破坏了读写互斥这一核心前提
- AQS 无法在共享计数 > 0 时安全授予独占锁，否则状态一致性无法保证
state 位域结构决定了升级不可行
ReentrantReadWriteLock 用一个 32 位 int 的高 16 位存读锁计数、低 16 位存写锁计数。这种拆分让读写状态天然隔离：
- 读锁增加：仅操作高 16 位，不影响写锁字段
- 写锁获取：需确保整个 state 为 0（即无读锁、无写锁），或当前线程已持写锁（重入）
- 已有读锁 → 高 16 位非零 → 写锁 acquire 条件失败 → 拒绝而非等待
这种位域设计本身就不预留“读锁→写锁”的转换路径，升级逻辑无处安放。
立即学习“Java免费学习笔记（深入）”；
避免活锁与状态歧义
如果强行支持升级，会引入难以收敛的竞态问题：
- 多个线程同时持读锁并尝试升级，谁该成功？按什么顺序？缺乏公平性定义
- 升级过程中若发生中断或超时，读锁是否该自动释放？语义不清晰
- 读锁可重入多次，升级时应降级哪一层？状态管理复杂度剧增
JDK 选择彻底禁止升级，换来语义明确、行为可预测、实现简洁——这是工程权衡后的稳健选择。
锁降级可行，是因为它符合状态单向演进
降级（写锁 → 读锁）能成立，关键在于它只发生在已稳持写锁的前提下：
- 写锁独占，此时无其他线程能修改数据，也无其他读锁正在进入
- 获取读锁只是增加共享计数，不改变排他性约束
- 随后释放写锁，但读锁仍在，保障“写后立刻读”的可见性，且不破坏互斥规则
这是一种受控的、单向的状态收缩，与升级这种需要打破现有共享状态的操作，本质不同。
