如何通过 ReadWriteLock 实现读写分离的并发控制优化
ReadWriteLock适用于读多写少场景,读写锁必须严格配对释放,且读操作不应包含非线程安全副作用。写操作占比超15%时性能可能不如synchronized,同时不保证读线程看到最新写入快照,使用需注意可见性。
ReadWriteLock 经常被误解为一种“读写分离”的实现模式,实际上它没那么复杂——它只是为读多写少场景设计的一种锁机制,专门解决多个读线程并发访问同一份共享资源的问题。它本身不拆分数据或逻辑,只控制对同一份共享资源的访问方式。

业内常说,搞懂 ReadWriteLock 的关键在于理解它“让读并发、让写独占”的哲学,但真正用起来,翻车的细节并不少。下面这几个要点,是实践中经常碰到的坑,值得记牢。
readLock() 和 writeLock() 必须严格配对释放
最基础也最容易翻车的一个点:调用 readLock().lock() 后,finally 块里误写成 writeLock().unlock()。Ja va 不校验锁类型匹配,运行时也不报错,结果就是锁永远无法释放,线程阻塞甚至死锁。这种事,全靠人工检查来兜底。
- 读操作:必须用
readLock().lock()+readLock().unlock() - 写操作:必须用
writeLock().lock()+writeLock().unlock() - 建议统一用 try/finally 包裹,避免因异常跳过 unlock
- 注意:持有写锁时不能再尝试获取读锁,
ReentrantReadWriteLock不支持锁升级,否则会死锁
读操作里不能包含非线程安全的副作用
这是个高频翻车现场。不少人把整个 getter 方法体包进 readLock(),觉得“加了锁就万事大吉”,结果在读过程中修改了本地变量、触发了远程调用、或者往 ThreadLocal 写了状态——这些行为都不受读锁保护,反而拖长锁持有时间,卡住所有写线程。
- 读锁只保证对被保护的共享对象(比如
cache)的读取是线程安全的 - 读操作中如果包含 I/O、RPC、日志打印、或构造新对象并赋值给局部变量,这部分逻辑应该移出锁块
- 尤其警惕“读缓存 → 缓存未命中 → 查 DB → 写缓存”这种混合流程:查 DB 和写缓存必须拆到写锁里
写操作占比超过 15% 时,ReadWriteLock 反而更慢
这一点值得多说几句。ReadWriteLock 的 lock/unlock 比 synchronized 多出 CAS、内存屏障、state 位运算等开销。当写线程频繁争抢写锁,或读锁被长期占用,公平性策略又开启时,整体吞吐可能反而比不上直接用 synchronized。
- 写操作频率超过 10%~15%,建议回归
synchronized或ReentrantLock - 读操作极轻量(比如只读一个
volatile int字段),加读锁纯属冗余 - 已用
ConcurrentHashMap等线程安全容器时,外层再套ReadWriteLock是典型误用,反而增加开销 - 如果业务允许弱一致性(比如缓存容忍短暂脏读),可考虑无锁方案,如
StampedLock的乐观读
最后补充一个容易被忽略的点:ReadWriteLock 不保证读线程看到的是“最新写入完成后的快照”,它只保证写锁释放后,后续读锁能看见变更。但如果写操作本身没做正确发布——比如没用 volatile 或 final 修饰引用对象——读线程仍可能拿到部分构造的对象,引发 NullPointerException 或字段默认值。这和锁无关,得靠对象初始化逻辑兜底。


































