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 Mapcache = 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, Functionloader) { // 先尝试读 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 是读多写少场景下的有效工具,关键是理解其行为模式,合理划分读写边界,避免锁升级和长耗时操作阻塞并发。用好了,能显著提升系统吞吐能力。











