reentrantreadwritelock不支持锁升级，根本原因是设计上禁止读锁→写锁转换：读写互斥语义、aqs状态校验（高16位非零即拒）、32位state位域隔离共同决定该路径不可行，强行升级必然导致死锁或语义混乱。
ReentrantReadWriteLock 不支持锁升级，根本原因不是代码写错了，而是设计上就禁止——它从语义、状态模型到并发安全都决定了“读锁 → 写锁”这条路走不通。
读写互斥是硬性前提，升级直接破坏契约
读锁允许多线程共享，写锁要求绝对独占。如果允许一个已持读锁的线程再获取写锁，等于让“读+写”共存，这违背了读写互斥的基本逻辑。AQS 无法在读锁计数 > 0 的状态下安全授予写锁，否则数据一致性无法保障。
- 多个线程同时持有读锁时，若其中某线程尝试升级，其他读线程仍可继续读——写操作就失去了排他保护
- 写锁的 acquire 条件明确要求 state 全为 0（无读锁、无写锁），或当前线程已是写锁持有者；已有读锁 → 高16位非零 → 条件失败 → 直接拒绝
位域结构天然阻断升级路径
ReentrantReadWriteLock 把 32 位 int 拆成高16位（读锁计数）和低16位（写锁计数）。这种设计让读写状态物理隔离：
- 读锁增加只动高16位，不影响写锁字段
- 写锁获取必须检查整个 state 是否满足独占条件，而读锁存在时该条件永远不成立
- 没有预留“从读锁状态切换到写锁状态”的中间位或转换逻辑
强行升级会引发不可控的活锁与语义混乱
即使绕过校验强行实现升级，也会带来工程上无法接受的问题：
- 多个线程同时持读锁并争抢升级，谁该成功？缺乏公平性定义，容易陷入无限重试
- 升级中途若被中断或超时，读锁是否该释放？释放后数据是否处于中间态？语义模糊
- 读锁可重入多次，升级时应降哪一层？状态管理复杂度指数级上升
死锁是怎么真实发生的
典型错误写法：readLock.lock(); if (cache.get() == null) writeLock.lock(); —— 看似顺理成章，实则埋下死锁炸弹：
- 线程拿到读锁后调用
writeLock.lock()，底层tryAcquire发现自己已持读锁，立刻返回 false - 随后进入 AQS 队列 park 等待，但读锁没释放，写锁又拿不到，其他线程也进不来
- 线程 dump 显示 WAITING(parking)，实际卡在写锁获取环节，形成“自己堵自己”的死锁表象
替代方案：降级可行，升级不行
锁降级（写锁 → 读锁）之所以安全，是因为它发生在写锁独占的前提下：
- 写锁已稳持，数据不会被其他线程修改
- 获取读锁只是增加共享计数，不破坏排他约束
- 随后释放写锁，读锁仍在，保证“写后立刻读”的可见性
- 这是单向、受控的状态收缩，与升级有本质区别
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
