Java中的ReentrantReadWriteLock是java.util.concurrent.locks包下实现读写分离的高效锁机制,适用于读多写少的并发场景。它通过区分读锁(共享锁)和写锁(独占锁),在保证线程安全的同时提升系统吞吐量。以下从核心特性、实现原理、使用方式及注意事项四方面详细解析:
一、核心特性
-
读写分离机制
- 读锁(Shared):允许多个线程同时获取读锁,适用于只读操作(如查询)。
- 写锁(Exclusive):仅允许一个线程获取写锁,适用于写操作(如修改)。写锁持有期间,其他线程(无论读或写)均被阻塞。
-
可重入性
同一线程可重复获取同一类型的锁(读锁或写锁),避免死锁。例如:ReentrantReadWriteLock lock = new ReentrantReadWriteLock(); lock.writeLock().lock(); // 获取写锁 lock.writeLock().lock(); // 可重入,不会阻塞 -
锁降级(Downgrade)
线程可先获取写锁,再获取读锁,最后释放写锁。此时其他线程可获取读锁,但无法获取写锁。例如:lock.writeLock().lock(); // 获取写锁 lock.readLock().lock(); // 降级为读锁(写锁未释放) lock.writeLock().unlock(); // 释放写锁(读锁仍持有) -
公平性与非公平性
支持公平模式(按请求顺序分配锁)和非公平模式(默认,写线程可能插队)。公平模式需显式构造:ReentrantReadWriteLock fairLock = new ReentrantReadWriteLock(true);
二、实现原理
基于AQS(AbstractQueuedSynchronizer)实现,内部维护两个锁:
- 读锁:通过共享模式(
sharedCount)管理,多个线程可同时持有。 - 写锁:通过独占模式(
exclusiveCount)管理,仅允许一个线程持有。
关键状态管理:
- 使用一个
int类型变量(如state)的高16位存储读锁持有数,低16位存储写锁重入次数。 - 写锁获取时,需检查读锁是否被其他线程持有(避免写锁饥饿);读锁获取时,需确保无写锁或当前线程持有写锁。
三、使用方式
-
基本API
ReentrantReadWriteLock lock = new ReentrantReadWriteLock(); Lock readLock = lock.readLock(); // 获取读锁 Lock writeLock = lock.writeLock(); // 获取写锁 // 读操作示例 readLock.lock(); try { // 执行只读操作 } finally { readLock.unlock(); } // 写操作示例 writeLock.lock(); try { // 执行写操作 } finally { writeLock.unlock(); } -
锁降级示例
writeLock.lock(); // 获取写锁 try { // 修改数据 readLock.lock(); // 降级为读锁(写锁未释放) } finally { writeLock.unlock(); // 释放写锁(读锁仍持有) }
四、注意事项
-
避免写锁饥饿
非公平模式下,写线程可能因读线程持续获取锁而饥饿。可通过公平模式或限制读锁持有时间缓解。 -
锁释放必须配对
每次lock()必须对应一次unlock(),通常在try-finally块中释放,防止死锁。 -
锁降级规则
- 仅支持“写锁→读锁”的降级,不支持“读锁→写锁”的升级。
- 写锁降级后,其他线程可获取读锁,但无法获取写锁。
-
性能权衡
在“读多写少”场景下性能提升显著;若写操作频繁,可能因锁竞争导致性能下降(此时考虑StampedLock或synchronized)。 -
中断支持
lockInterruptibly()方法允许线程在阻塞时响应中断,需配合tryLock()使用。
五、适用场景
- 缓存系统(如Redis客户端、本地缓存)
- 配置中心(频繁读取、少修改)
- 数据库连接池(读操作多,写操作少)
- 资源访问统计(如计数器、状态监控)
总结:ReentrantReadWriteLock通过读写分离和可重入特性,在并发场景中平衡了安全性与性能。使用时需根据业务特点(读/写比例、锁持有时间)选择公平模式或非公平模式,并注意锁的获取/释放配对及降级规则,避免死锁和性能损耗。在Java 8之后,也可结合StampedLock进一步优化性能(如乐观读)。

4130

被折叠的 条评论
为什么被折叠?



