之前讲了《AQS源码阅读》和《ReentrantLock源码阅读》,本次将延续阅读下ReentrantReadWriteLock,建议没看过之前两篇文章的,先大概了解下,有些内容会基于之前的基础上阅读。
这个并不是ReentrantLock简单的升级,而是落地场景的优化,我们来详细了解下吧。
背景
JUC包里面已经有一个ReentrantLock了,为何还需要一个ReentrantReadWriteLock呢?看看头注解找点线索。
它是ReadWriteLock接口的实现。那看看这个接口怎么说
<!-- more -->
在实际场景中,一般来说,读数据远比写数据要多。如果我们还是用独占锁去锁线程避免线程不安全的话,是非常低效的,而且同时也会失去它的并发性。多线程也没有意义了。所以ReadWriteLock就是解决这个问题所存在的。
看回ReentrantReadWriteLock的头注解。
ReentrantReadWriteLock依然有公平锁/非公平锁的功能,与ReentrantLock不同在于,前者内部维护了读锁和写锁,在公平/非公平模式下,他们会一起去竞争这个锁资源。
上图是两条ReentrantReadWriteLock最核心的规则。
- 申请读锁。当没有其他写锁占有,或者读锁在队列中排队时间最长的,才能成功
- 申请写锁。当没有其他线程占有读/写锁的情况下,才能成功
又以上两条规则可以推导出,
- 写锁比读锁要高级
- 有读锁占用可以继续申请读锁,但其他线程不能申请写锁
- 有写锁占用其他线程读写都不能申请
所以扣ReadWriteLock接口的说明,可以让读并发,写独占,提高了程序的并发性。
ReentrantReadWriteLock构成
看下ReentrantReadWriteLock的file struture
之前看过ReentrantLock源码的同学肯定很熟悉这个结构,看起来相同的都是Sync同步器(AQS的子类),以及它的两个公平/非公平子类。
不同的是它还多了ReadLock内部类和WriteLock内部类,以及读写对应的成员变量和方法。并且少了lock()、unlock()等方法,而是把加锁解锁的功能下方给这两个子类,符合ReadWriteLock接口的定义。
Sync内部类
虽然ReentrantReadWriteLock和ReentrantLock都有Sync,但其实Sync方法已经很大不同了,看下Sync的结构
对比之前ReentrantLock的Sync,最大不同在于它多了**shared()方法,用于共享锁的获取与释放。
另外tryReadLock()、tryWriteLock()是给WriteLock和ReadLock内部类使用的。
tryAcquire() 独占锁(写锁)申请
上文介绍重入锁说到state代表的是重入的次数,在读写锁的语义下,state代表的读/写占有(重入)的次数。c为state,w为独占重入次数。
当有线程占用锁时(c!=0),如果没有写锁(w==0)或者独占线程不是当前线程,返回false获取失败。锁的重入总数超过上限会抛出异常。
这里很容易看出来,如果有锁占用的时候,如果只是读锁,依然可以申请成功。这就是读锁的锁升级。
当没有线程占用的时候,执行writerShouldBlock()判断是否需要阻塞线程(子类实现自己的条件),不需要则CAS state值,返回成功。
tryAquireShared() 共享锁(读锁)申请
读锁申请比写锁申请要复杂,有比较多没接触过的成员变量,判断的语句也比较多。
先看看成员变量,从他们各自的变量注解可知
- firstReader,是第一个获取读锁的线程
- firstReaderHoldCount,是firstReader的计数器。
- cachedHoldCounter,最近一个成功获取读锁的线程持有数计数器。
- readHolds,当前线程重入读锁次数。ThreadLocal<HoldCounter>,是线程安全的HoldCounter。
先判断是否有写锁占有,如果写锁不是当前线程,获取读锁失败,退出方法。
注意如果写锁是当前线程是可以获取读锁的,因为写锁是独占的,这种情况下是不会有数据与其他线程共享的问题。
满足子类条件,也不超过总数,CAS也成功的情况下,
如果没有读锁,则设firstReader为当前线程,firstReaderHoldCount为1;
如果有读锁,并且也是当前线程申请获取,firstReaderHoldCount自增1;
如果有读锁,不是当前线程申请,取上一个成功的缓存计数器,如果这个计数器不是当前线程的,则设为当前的计数器,并且自增,返回成功。(其实就是把缓存计数器置换为当前线程的计数器)
最后不满足条件或者CAS失败,执行fullTryAcquireShared(current)返回。
至于这些数据算来干嘛,等后面看看release()怎么用。
其实这个方法就是用for循环轮询解决CAS丢失和重入失败的问题,具体代码不细过了,有兴趣可以自己找源码看看。
tryRelease() 独占锁(写锁)释放
这里又有Condition的踪迹了,大概可以才行到Condition时控制锁的行为的,取消唤醒等操作。
另外锁会同时释放读锁和写锁。
这个方法比较好理解的,只要是当前线程操作下,持有重入数减去释放数为0就可以释放了,否则失败。
tryReleaseShared() 共享锁(读锁)释放
释放读锁,对正在读的线程不会有什么影响,但可以让等待的写线程去开始获取写锁。
剩余的内容就是对tryAquireShared()计算的count数值进行释放(自减),如果最终自减为0则释放读锁成功。
WriteLock、ReadLock内部类
前面说到ReentrantReadWriteLock的lock()、unlock()操作是分配到Write/ReadLock里面执行的。
他们都是Lock接口的实现,所以其实最像ReentrantLock应该是这个两个内部类。而且大体上也没什么差异,也是用Sync的内部类。
WriteLock、ReadLock最大的不同就是WriteLock用的独占模式的方法,ReadLock用的是共享模式的方法。
具体的代码实现基本就是上面说明的组成,下面介绍下ReentranReadWriteLock的使用。
ReentrantLock的时候比较简单,声明一个变量,调用lock()方法即可。
ReentrantLock rl = new ReentrantLock();
rl.lock();
rl.unlock();
但ReentranReadWriteLock并不是Lock接口的实现,所以没有这些方法。
有的只是writeLock()、readLock(),要先调用这个方法获取应对的锁对象,再调用lock()。
ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
rwl.readLock().lock();
rwl.readLock().unlock();
rwl.writeLock().lock();
rwl.writeLock().unlock();
总结
回顾下要点
- 读写锁ReentrantReadWriteLock,是基于多读少写的实际场景,提高并发性
- 读写锁的Sync添加了共享模式的方法
- 读写锁内置了两个对象readLock、writeLock,用于实际的加锁解锁
- 写锁是独占的,不允许其他锁的申请
- 读锁可以并发重复申请,当有写锁的时候,会发生锁升级
特别地,在此祝福8月27日生日的她。
更多技术文章、精彩干货,请关注
博客:zackku.com
微信公众号:Zack说码
原文地址:http://blog.51cto.com/14073604/2317964