读写锁适用于读多写少场景，通过分离读锁（共享）和写锁（独占）降低线程争用；reentrantreadwritelock支持锁降级但不支持升级；性能优势依赖读写比例与临界区长度，写占比超15%～20%时可能劣于普通锁；公平模式可缓解饥饿但增加开销。
读写锁解决的是读多写少场景下的线程阻塞问题
当多个线程频繁读取共享数据、但写操作极少时，用 synchronized 或普通 ReentrantLock 会导致所有读线程互相阻塞——哪怕读操作本身是线程安全的。读写锁把“读”和“写”两种行为拆开：读锁可重入且允许多个线程同时持有，写锁则独占且排斥所有读锁。本质是用更细粒度的锁协议降低争用。
ReentrantReadWriteLock 的读锁和写锁不能混用
常见错误是误以为获取了读锁后能直接修改数据，或在持有写锁时又去尝试获取读锁（会死锁）。必须严格区分使用边界：
- 只读逻辑 → 获取
readLock().lock()，完成后unlock() - 写逻辑 → 获取
writeLock().lock()，完成后unlock() - 读锁未释放前，任何线程调用
writeLock().lock()会阻塞 - 写锁未释放前，任何线程调用
readLock().lock()也会阻塞 - 写锁可降级为读锁（调用
writeLock().unlock()后再readLock().lock()），但不可升级（持有读锁时无法获得写锁）
性能提升取决于读写比例和临界区长度
读写锁不是银弹。如果写操作占比超过 15%～20%，或者每次读操作耗时极短（如只是读一个 int 字段），那么读写锁的额外状态管理开销（如内部队列、CAS 操作）反而可能比纯排他锁更慢。实测建议：
- 用
JMH对比ReentrantLock和ReentrantReadWriteLock在目标场景下的吞吐量 - 注意 JVM 参数影响：高并发下
-XX:+UseBiasedLocking可能削弱读写锁优势 - 避免在读锁内做 I/O、远程调用或长循环——这会让其他线程长时间饥饿
公平性设置容易被忽略但影响调度行为
ReentrantReadWriteLock 默认是非公平的，即写线程可能插队抢占刚释放的锁，导致读线程饥饿。若业务对响应时间敏感（比如实时报表服务），应显式启用公平模式：
立即学习“Java免费学习笔记（深入）”；
new ReentrantReadWriteLock(true); // true 表示公平
但公平模式会带来更高上下文切换开销，在高吞吐写场景下可能拉低整体吞吐。是否开启，得看监控里 getQueueLength() 是否持续偏高，以及 hasQueuedThreads() 返回值是否频繁为 true。
