ReadWriteLock通过“读读共享、读写互斥”语义实现按操作类型区分管控，在读多写少场景下显著提升并发吞吐量；其非公平模式默认更优，读操作可近乎并行执行，写操作仅阻塞必要线程，但误用（如读锁内耗时操作或尝试锁升级）反而导致性能下降。
ReadWriteLock 通过“读读共享、读写互斥”的语义重构，把锁从“一刀切的独占”变成“按操作类型区分管控”，在读多写少场景下显著提升并发吞吐量。
读操作真正并行化，不排队
多个线程同时获取读锁不会互相阻塞——只要没有写锁被持有，它们就能并发进入临界区。这和 synchronized 或 ReentrantLock 完全不同，后者无论读写都强制串行排队。
- 例如缓存查价：100 个读请求同时到来，用普通锁需逐个处理；用读写锁可近乎并行完成，QPS 理论上接近线性增长
- CPU 缓存行复用更高效，多个读线程密集访问同一块内存，减少主存访问延迟
- 线程上下文切换大幅减少，调度开销明显下降
写操作只精准阻塞必要线程
写锁是独占的，但它的影响范围被严格限定：仅阻塞新来的读请求，已获得读锁的线程不受干扰，也不会被中途中断。
- 写线程必须等待所有当前读锁释放后才能获取写锁，确保写入前数据状态一致
- 一旦写锁成功获取，后续读请求会被挂起，但已执行的读操作照常完成
- 写操作本身不因读锁存在而变慢，只是获取时机取决于读锁持有时长
避免误用，否则反而更慢
读写锁不是“用了就快”，错误用法会放大开销：
立即学习“Java免费学习笔记（深入）”；
- 读锁内做耗时操作（如远程调用、大对象拷贝），会导致写线程长期饥饿
- 忘记在 finally 块中 unlock()，或跨线程释放，引发死锁或持续阻塞
- 在持有读锁时直接调 writeLock().lock() —— JVM 不支持读锁升级，会永久阻塞
- 写操作占比超过 20%，锁协调成本反超收益，此时应回退到 ReentrantLock
非公平模式默认更优
new ReentrantReadWriteLock() 默认使用非公平模式，适合绝大多数生产环境：
- 新来的读线程可能插队，略微增加写线程等待时间，但整体吞吐高 15%～30%
- 公平模式唤醒逻辑更重，且无法缓解“大量读锁未释放”导致的写饥饿
- 除非监控发现写锁平均等待超 50ms，否则无需启用公平模式
