ReentrantReadWriteLock禁止锁升级，因AQS校验到线程已持读锁时会直接拒绝写锁获取并无限park，导致死锁；安全做法是用tryLock()替代lock()，或采用锁降级保障可见性。
Java 中 ReentrantReadWriteLock 不允许锁升级，即线程在持有读锁（ReadLock）的情况下，调用写锁（WriteLock）的 lock() 方法会永久阻塞，形成死锁表象。这不是 bug，而是明确的设计约束。
为什么锁升级被禁止
核心在于 AQS 的状态校验逻辑：当线程已持读锁时，writeLock.lock() 会先检查是否有其他写锁占用；确认无竞争后，立即检查「当前线程是否已持读锁」——结果为真，便直接拒绝获取写锁，并将线程加入 AQS 队列无限 park。
- 读锁未释放，写锁又无法获取，线程卡在 WAITING(parking) 状态
- 其他线程也无法获取写锁（因读锁仍存在），且新读请求也会被阻塞（写锁已在排队）
- 单一线程“半占”锁资源，导致整个读写锁系统陷入全局阻塞
典型错误代码模式
缓存加载中常见的「读-判断-写」链极易触发该问题：
- 先
readLock.lock()查询缓存 - 发现 miss，不释放读锁，直接调用
writeLock.lock() - 多个并发线程同时卡在同一行，服务逐渐夯死
这种写法在高并发下无法靠超时或重试缓解，因为 lock() 是无条件阻塞，失败路径根本不存在。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
唯一安全的替代方式是 tryLock()
真正可落地的协调逻辑必须绕开「持读锁再抢写锁」路径：
- 优先用
writeLock.tryLock(100, TimeUnit.MILLISECONDS)尝试抢占写锁；成功则双检写入，失败则退避或 fallback - 若必须走读优先路径，只能用
readLock.tryLock()非阻塞获取；失败立即重试或让出 CPU，绝不调用lock() - 锁降级仅适用于「已稳持写锁 → 获取读锁 → 释放写锁」这一单向流程，且不能混入异常、异步或定时逻辑
锁降级不是为了省开销，而是保可见性
锁降级的唯一正当用途，是保障「写后立刻读」的数据可见性——写锁释放前先获取读锁，确保后续读操作看到刚写入的最新值。
- 把它当成通用流程嵌套进 if/else 或 try/catch，极易遗漏
tryLock()的失败处理 - 一旦失败路径覆盖不全，不如统一用写锁兜底：逻辑更清晰，风险更可控
