ReadWriteLock 是为读多写少场景设计的并发锁机制，非读写分离模式；需严格配对 readLock/writeLock 的 lock/unlock，禁用锁升级，避免读操作含副作用，写频超15%时性能反降。
ReadWriteLock 不是用来“实现读写分离”的设计模式，而是为读多写少场景提供一种原生支持并发读的锁机制；它本身不拆分数据或逻辑，只控制对同一份共享资源的访问方式。
ReadWriteLock 的 readLock() 和 writeLock() 必须严格配对释放
常见错误是调用 readLock().lock() 后，在 finally 块里误写成 writeLock().unlock()，导致锁永远无法释放，最终线程阻塞甚至死锁。Java 不校验锁类型匹配，运行时也不会报错，只能靠人工检查。
- 读操作必须用
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 或字段默认值。这和锁无关，得靠对象初始化逻辑兜底。
