ReentrantReadWriteLock通过读写锁分离提升高读低写性能：读锁共享可重入，写锁独占可重入，读写互斥但读读不互斥；支持写锁降级为读锁，禁止读锁升级；适用于缓存等场景。
ReentrantReadWriteLock 通过分离读操作和写操作的锁机制，让多个读线程可以同时执行，而写操作独占锁，从而显著提升高读低写的并发场景性能。关键在于：读锁可重入、共享；写锁可重入、独占；读写互斥，写写互斥，但读读不互斥。
理解读写锁的基本行为
ReentrantReadWriteLock 内部维护一对锁：ReadLock 和 WriteLock。它们共享同一个同步状态，但控制逻辑不同：
- 多个线程可同时获取 ReadLock（只要没有线程持有 WriteLock）
- WriteLock 是排他锁，获取时要求既无其他 WriteLock，也无任何 ReadLock 在持有中
- 锁支持重入：同一线程可多次获取自己已持有的读锁或写锁
- 写锁可降级为读锁（先获取写锁，再获取读锁，最后释放写锁），但读锁不能升级为写锁（会死锁）
典型使用模式：读多写少的数据缓存
适用于如配置中心、本地缓存、元数据快照等场景。以一个简单缓存为例：
private final Map<string object> cache = new HashMap();
private final ReadWriteLock lock = new ReentrantReadWriteLock();
private final Lock readLock = lock.readLock();
private final Lock writeLock = lock.writeLock();
public Object get(String key) {
readLock.lock();
try {
return cache.get(key);
} finally {
readLock.unlock();
}
}
public Object put(String key, Object value) {
writeLock.lock();
try {
return cache.put(key, value);
} finally {
writeLock.unlock();
}
}
</string>
注意：读操作必须用 try-finally 确保解锁；写操作同理。避免在持有读锁时修改共享数据（违反锁契约），也不应在持有写锁期间调用可能阻塞或回调读操作的方法。
进阶技巧：写锁降级与锁顺序安全
当需要“先检查再更新”且保证中间状态不被干扰时，可利用写锁降级：
- 先获取写锁 → 检查条件 → 修改数据 → 获取读锁 → 释放写锁 → 后续只读访问
- 这样能确保从检查到修改再到降级完成前，无其他线程介入
- 必须按「写锁 → 读锁 → 释放写锁」顺序，不可颠倒；否则可能因读锁未获取就释放写锁，导致数据被其他写线程篡改
示例：实现一个带过期检查的懒加载缓存项更新逻辑，适合在首次读取并发现过期时触发刷新，且刷新过程需原子性。
注意事项与常见陷阱
实际使用中容易忽略以下细节：
- 不要嵌套读锁+写锁：同一线程先持读锁再申请写锁会永久阻塞（读写互斥，且读锁未释放）
- 锁粒度要合理：避免把整个方法体包在锁里，尤其是含 I/O、远程调用或长时间计算的逻辑
- 公平性选择需谨慎：new ReentrantReadWriteLock(true) 开启公平模式可减少写饥饿，但会降低吞吐量，多数场景用非公平默认即可
- 监控与排查：可通过 getReadLockCount()、isWriteLocked() 等方法调试；生产环境建议配合 JMX 或日志记录锁等待情况
不复杂但容易忽略。用对时机，读写锁是提升并发读性能的轻量利器。
