ReadWriteLock通过读写分离提升缓存吞吐量：读并发、写独占，适配高读低写场景；95%读请求下QPS可达互斥锁的3～5倍；需规范读写路径与锁管理避免死锁和泄露。
ReadWriteLock 在缓存场景中提升吞吐量，核心在于它把“读”和“写”两类操作做了权限分离：读可以并发，写必须独占。这正好匹配缓存的典型行为——大量查询、极少更新。
读操作不再互相阻塞
普通锁（如 ReentrantLock）下，哪怕只是查缓存，所有线程也得排队。而 ReadWriteLock 允许多个读线程同时进入，比如 100 个线程查同一份用户权限配置，它们能并行执行，不抢同一把锁。
- 调度开销明显下降，线程上下文切换大幅减少
- CPU 缓存行复用率提高，多个读线程访问相同内存区域，命中缓存概率更高
- 实际中，95% 以上是读请求时，QPS 可比纯互斥锁高 3～5 倍
写操作只在必要时才阻塞其他线程
缓存更新（如刷新配置、失效旧条目）频率低，ReadWriteLock 让写锁只在真正需要时才生效，且仅阻塞“那一刻”正在读或写的线程。
- 写操作不会拖慢绝大多数读请求，避免了“一次写卡住全部读”的瓶颈
- 写锁获取后，会等待当前活跃读操作完成，再独占执行，保障数据一致性
- 写完立即释放，后续读请求又能快速并发执行，延迟更平稳
适合缓存的典型使用模式
不是简单套用，而是配合缓存语义设计代码结构：
立即学习“Java免费学习笔记（深入）”；
- 读路径：只调 readLock().lock() → get() → unlock()，全程不修改共享数据
- 写路径：必须用 writeLock().lock() → put()/clear() → unlock()，确保写入原子性与可见性
- 按需加载（Lazy Load）场景：先尝试读，发现缺失再降级加写锁加载，避免重复初始化
注意几个关键细节
用对了机制，但细节不到位也容易出问题：
- 读锁内不能调用写操作，否则可能死锁；写锁可降级为读锁，但需按规范顺序操作
- 避免在锁内做耗时操作（如远程调用、复杂计算），否则拖长锁持有时间
- 推荐配合 try-finally 或 try-with-resources 保证锁必然释放，防止线程挂起导致锁泄露
