reentrantreadwritelock 不支持读锁升级为写锁，否则会导致死锁；安全做法是锁降级（写锁→读锁）或直接用trylock获取写锁重建缓存。
ReentrantReadWriteLock 在缓存重建场景中极易因误用锁升级逻辑导致隐性死锁，核心问题不是并发控制没做好，而是对「读锁→写锁」这一路径的误判——它根本不可行。真正安全的做法是绕开升级、用降级、或干脆放弃读锁前置。
缓存重建中最危险的写法：先读锁再调 writeLock.lock()
这是线上高频死锁源头。线程持读锁后调用 writeLock.lock()，JDK 会立即拒绝（因校验到当前线程已持读锁），并让线程进入 WAITING 状态；而读锁未释放，写锁又拿不到，其他线程也被阻塞，形成全局卡顿。
- 看似合理：“我先看看缓存有没有，没有再写”
- 实际执行：readLock.lock() → if (cache == null) → writeLock.lock() → 永久挂起
- 线程 dump 显示 WAITING at ReentrantReadWriteLock$ReadLock.lock，但真实阻塞点在写锁获取环节
锁降级不是“省一次锁”，而是保数据一致性
锁降级只允许「写锁 → 读锁」，且必须严格按顺序：获取写锁 → 修改数据 → 获取读锁 → 释放写锁 → 继续读操作。它解决的是“写完立刻读、且不被其他写入干扰”的连续性需求，不是为了简化流程。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 正确顺序：writeLock.lock() → 修改 → readLock.lock() → writeLock.unlock() → 读取 → readLock.unlock()
- 关键点：readLock.lock() 必须发生在 writeLock.unlock() 之前，否则可能被其他线程抢占写锁
- volatile 字段（如 cacheValid）需配合使用，确保状态变更对其他线程可见
更健壮的缓存重建方案：跳过读锁，直接 tryLock 写锁
在高并发缓存 miss 场景下，“先读再写”天然存在竞态窗口。与其在读锁里挣扎升级，不如一开始就用写锁协调，失败则退避重试。
- 首选策略：writeLock.tryLock(100, TimeUnit.MILLISECONDS)，成功则双检后更新，失败则 fallback 到等待或异步加载
- 避免嵌套：绝不把 readLock.lock() 和 writeLock.lock() 放在同一 try 块或条件分支中
- 若必须支持高并发读+低频写，可用双重检查 + volatile + 写锁兜底，而非依赖读锁保护判断逻辑
容易被忽略的细节：tryLock 是降级唯一安全入口
readLock.tryLock() 是唯一可接受的读锁获取方式。用 readLock.lock() 获取读锁后，哪怕只做一次判断，也埋下隐患——高并发下读锁计数可能已达上限，后续 tryLock 写锁时反而因读锁未释放而自挂起。
- 非阻塞读锁 + 写锁抢占，比“读锁升写锁”更可控、更易测试
- 所有异常路径必须确保锁释放，尤其 writeLock.unlock() 不可在 try 外部调用
- 锁降级仅适用于写后紧接读的短逻辑；若中间夹杂 IO、远程调用或复杂计算，应放弃降级，改用纯写锁保护整个流程
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
