ReentrantReadWriteLock通过读共享、写独占机制提升读多写少场景的并发性能，允许多个读线程同时访问，写线程独占锁，避免锁升级和长耗时操作，结合try-finally确保锁释放，适用于缓存等高频读取场景。
在高并发场景中，多个线程对共享资源的读写操作容易引发性能瓶颈。Java 提供了 ReentrantReadWriteLock 来优化这种场景下的性能表现。相比传统的 synchronized 或 ReentrantLock，它允许多个读线程同时访问资源，而写线程独占访问，从而提升读多写少情况下的吞吐量。
理解读写锁的基本原理
ReentrantReadWriteLock 维护了一对锁：一个用于读操作的共享锁，一个用于写操作的排他锁。
- 读锁（共享）：多个线程可以同时获取读锁，适用于只读操作。
- 写锁（独占）：同一时刻只能有一个线程持有写锁，且此时不允许任何读线程进入。
这种机制特别适合“频繁读取、较少修改”的数据结构，比如缓存、配置管理器等。
正确使用读写锁的代码模式
使用时必须确保锁的获取与释放成对出现，推荐用 try-finally 结构避免死锁。
立即学习“Java免费学习笔记（深入）”；
private final ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock();
private final Lock readLock = rwLock.readLock();
private final Lock writeLock = rwLock.writeLock();
private Map<String, Object> cache = new HashMap<>();
// 读操作
public Object get(String key) {
readLock.lock();
try {
return cache.get(key);
} finally {
readLock.unlock();
}
}
// 写操作
public void put(String key, Object value) {
writeLock.lock();
try {
cache.put(key, value);
} finally {
writeLock.unlock();
}
}
注意：不要在持有读锁时尝试获取写锁，否则会导致死锁。
避免锁升级，合理设计访问逻辑
ReentrantReadWriteLock 不支持从读锁直接“升级”为写锁。如果一个线程持有读锁并试图获取写锁，会一直阻塞自己。
- 若需更新数据，建议先释放读锁，再申请写锁。
- 或者在调用前判断是否需要写操作，直接请求写锁。
例如：
public Object computeIfAbsent(String key, Function<String, Object> loader) {
// 先尝试读
readLock.lock();
Object result = cache.get(key);
if (result != null) {
readLock.unlock();
return result;
}
// 需要加载，切换到写锁
readLock.unlock();
writeLock.lock();
try {
// 再次检查，防止重复计算（双检锁）
result = cache.get(key);
if (result == null) {
result = loader.apply(key);
cache.put(key, result);
}
return result;
} finally {
writeLock.unlock();
}
}
性能优化建议与注意事项
虽然读写锁能提升并发性能，但不当使用反而会降低效率。
- 读写比例要高：只有当读操作远多于写操作时，优势才明显。
- 避免长时间持有写锁：写操作应尽量轻量，减少阻塞其他线程。
- 考虑使用StampedLock：对于更复杂的场景（如乐观读），可考虑 JDK 8 引入的 StampedLock，性能更高但使用更复杂。
- 监控锁竞争情况：通过 JMX 或 profiling 工具观察锁等待时间，判断是否真有性能收益。
基本上就这些。ReentrantReadWriteLock 是读多写少场景下的有效工具，关键是理解其行为模式，合理划分读写边界，避免锁升级和长耗时操作阻塞并发。用好了，能显著提升系统吞吐能力。
