如何通过 ReadWriteLock 实现读写分离的并发控制优化

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 或字段默认值。这和锁无关，得靠对象初始化逻辑兜底。