码迷,mamicode.com
首页 > 编程语言 > 详细

Java多线程——ReentrantReadWriteLock源码阅读

时间:2018-11-16 20:41:44      阅读:192      评论:0      收藏:0      [点我收藏+]

标签:背景   follow   slim   href   多线程   readwrite   自增   避免   qiniu   

之前讲了《AQS源码阅读》《ReentrantLock源码阅读》,本次将延续阅读下ReentrantReadWriteLock,建议没看过之前两篇文章的,先大概了解下,有些内容会基于之前的基础上阅读。
这个并不是ReentrantLock简单的升级,而是落地场景的优化,我们来详细了解下吧。

背景

JUC包里面已经有一个ReentrantLock了,为何还需要一个ReentrantReadWriteLock呢?看看头注解找点线索。
技术分享图片
它是ReadWriteLock接口的实现。那看看这个接口怎么说
技术分享图片<!-- more -->
在实际场景中,一般来说,读数据远比写数据要多。如果我们还是用独占锁去锁线程避免线程不安全的话,是非常低效的,而且同时也会失去它的并发性。多线程也没有意义了。所以ReadWriteLock就是解决这个问题所存在的。
看回ReentrantReadWriteLock的头注解。
技术分享图片
ReentrantReadWriteLock依然有公平锁/非公平锁的功能,与ReentrantLock不同在于,前者内部维护了读锁和写锁,在公平/非公平模式下,他们会一起去竞争这个锁资源。
技术分享图片
上图是两条ReentrantReadWriteLock最核心的规则。

  1. 申请读锁。当没有其他写锁占有,或者读锁在队列中排队时间最长的,才能成功
  2. 申请写锁。当没有其他线程占有读/写锁的情况下,才能成功

又以上两条规则可以推导出,

  1. 写锁比读锁要高级
  2. 有读锁占用可以继续申请读锁,但其他线程不能申请写锁
  3. 有写锁占用其他线程读写都不能申请

所以扣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();

总结

回顾下要点

  1. 读写锁ReentrantReadWriteLock,是基于多读少写的实际场景,提高并发性
  2. 读写锁的Sync添加了共享模式的方法
  3. 读写锁内置了两个对象readLock、writeLock,用于实际的加锁解锁
  4. 写锁是独占的,不允许其他锁的申请
  5. 读锁可以并发重复申请,当有写锁的时候,会发生锁升级

特别地,在此祝福8月27日生日的她。


更多技术文章、精彩干货,请关注
博客:zackku.com
微信公众号:Zack说码
技术分享图片

Java多线程——ReentrantReadWriteLock源码阅读

标签:背景   follow   slim   href   多线程   readwrite   自增   避免   qiniu   

原文地址:http://blog.51cto.com/14073604/2317964

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!