之前讲了《AQS源码阅读》和《ReentrantLock源码阅读》，本次将延续阅读下ReentrantReadWriteLock，建议没看过之前两篇文章的，先大概了解下，有些内容会基于之前的基础上阅读。 这个并不是ReentrantLock简单的升级，而是落地场景的优化，我们来详细了解下吧。 背景 JUC包里面已经有一个ReentrantLock了，为何还需要一个ReentrantReadWriteLock呢？看看头注解找点线索。 它是ReadWriteLock接口的实现。那看看这个接口怎么说 在实际场景中，一般来说，读数据远比写数据要多。如果我们还是用独占锁去锁线程避免线程不安全的话，是非常低效的，而且同时也会失去它的并发性。多线程也没有意义了。所以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。 先判断是否有写锁占有，如果写锁不是当前线程，获取读锁失败，退出方法。 注意如果写锁是当前线程是可以获取读锁的，因为写锁是独占的，这种情况下是不会有数据与其他线程共享的问题。 满足子类条件，也不超过总数，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.comhttps://www.cnblogs.com/zackku/p/9993126.html