ReadWriteLock 比 synchronized 更适合读多写少场景，因其允许多个读线程并发、仅写操作独占；但需注意不可锁升级、必须手动配对释放、非公平模式可能导致写线程饥饿。
ReadWriteLock 为什么比 synchronized 更适合读多写少
当多个线程频繁读、极少写时，用 synchronized 会让所有读操作排队等待，白白牺牲并发性。而 ReentrantReadWriteLock 允许同时多个读线程进入，只在写时独占——这是它存在的根本理由。
关键点在于：读锁可重入、读锁与读锁不互斥、读锁与写锁互斥、写锁与写锁互斥。不是“读写分离”的魔法，而是明确的锁协议设计。
- 读操作多于写操作 10 倍以上时，性能优势才明显；写占比超 5%，收益快速衰减
-
ReentrantReadWriteLock默认是非公平锁，高并发下可能饿死写线程，需根据场景决定是否启用公平模式（构造函数传true） - 不能升级：持有读锁后调用
writeLock().lock()会死锁，JVM 不允许锁升级
正确获取和释放读锁与写锁
必须成对调用 lock() / unlock()，且不能跨线程释放——这点和 synchronized 的自动释放完全不同，漏掉 unlock() 就等于永久占锁。
推荐始终用 try-finally 保证释放，尤其注意：读锁和写锁是两个独立对象，别混用。
立即学习“Java免费学习笔记（深入）”；
private final ReadWriteLock rwLock = new ReentrantReadWriteLock();
private final Lock readLock = rwLock.readLock();
private final Lock writeLock = rwLock.writeLock();
// 读操作
public String getValue() {
readLock.lock();
try {
return data;
} finally {
readLock.unlock();
}
}
// 写操作
public void setValue(String value) {
writeLock.lock();
try {
data = value;
} finally {
writeLock.unlock();
}
}
getReadLockCount() 和 getWriteHoldCount() 调试时怎么用
这两个方法不用于业务逻辑判断，只在排查锁泄漏或验证锁行为时有用。它们返回的是当前线程持有的锁数量（写锁可重入，所以是计数），不是全局等待线程数。
-
rwLock.getReadLockCount()：返回所有线程持有的读锁总数（非当前线程） -
readLock.getHoldCount()：仅当前线程对读锁的重入次数 -
writeLock.getHoldCount()：当前线程对写锁的重入次数，为 0 表示未持有写锁 - 这些值在生产环境开启 JMX 或通过
jstack查看线程堆栈更可靠，代码中不应依赖它们做流程控制
StampedLock 替代 ReadWriteLock？要看是否需要乐观读
StampedLock 提供了 tryOptimisticRead()，适合读操作极快、冲突概率极低的场景（比如读一个 long 计数器）。但它不支持重入、不支持条件变量、写锁也不可中断——和 ReentrantReadWriteLock 是不同定位。
- 如果读操作涉及多个字段、需保持一致性，或读逻辑稍长（> 几微秒），乐观读大概率失败，反而比直接用读锁更慢
-
validate(stamp)返回false后，必须降级为悲观读（readLock()），这部分逻辑容易漏写 - 除非你明确知道乐观读能带来收益，并愿意承担额外复杂度，否则默认选
ReentrantReadWriteLock
