Java多线程进阶—— J.U.C之locks框架：基于AQS的读写锁(5)

妖狐艹你老母 2023-06-21 08:57 116阅读 0赞

## 一、本文概述 ##

AQS系列的前四个章节，已经分析了AQS的原理，本文将会从`ReentrantReadWriteLock`出发，给出其内部利用AQS框架的实现原理。

ReentrantReadWriteLock（以下简称RRW），也就是读写锁，是一个比较特殊的同步器，特殊之处在于其对同步状态State的定义与ReentrantLock、CountDownLatch都很不同。通过RRW的分析，我们可以更深刻的了解AQS框架的设计思想，以及对***“什么是资源？如何定义资源是否可以被访问？”***这一命题有更深刻的理解。

## 二、本章示例 ##

和之前的章节一样，本文也通过示例来分析RRW的源码。

> 假设现在有4个线程，ThreadA、ThreadB、ThreadC、ThreadD。  
> ThreadA、ThreadB、ThreadD为读线程，ThreadC为写线程：
> 
> 初始时，构造RRM对象：  
> `private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();`  
> `private final Lock r = rwl.readLock();`  
> `private final Lock w = rwl.writeLock();`

//ThreadA调用读锁的lock()方法
    
    //ThreadB调用读锁的lock()方法
    
    //ThreadC调用写锁的lock()方法
    
    //ThreadD调用读锁的lock()方法

## 三、RRW的公平策略原理 ##

### 1. RRW对象的创建 ###

和ReentrantLock类似，ReentrantReadWriteLock的构造器可以选择公平/非公平策略（默认为非公平策略），RRW内部的`FairSync`、`NonfairSync`是AQS的两个子类，分别代表了实现公平策略和非公平策略的同步器：

![clipboard.png][]

ReentrantReadWriteLock提供了方法，分别获取读锁/写锁：

![clipboard.png][clipboard.png 1]

`ReentrantReadWriteLock.ReadLock`和`ReentrantReadWriteLock.WriteLock`其实就是两个实现了Lock接口的内部类:

![clipboard.png][clipboard.png 2]

### 2. ThreadA调用读锁的lock()方法 ###

读锁其实是一种共享锁，实现了AQS的共享功能API，可以看到读锁的内部就是调用了AQS的**acquireShared**方法，该方法前面几章我们已经见过太多次了：

![clipboard.png][clipboard.png 3]

关键来看下ReentrantReadWriteLock是如何实现**tryAcquireShared**方法的：  
读锁获取成功的条件如下：

1.  写锁没有被其它线程占用（可被当前线程占用，这种情况属于锁降级）
2.  等待队列中的队首没有其它线程（公平策略）
3.  读锁重入次数没有达到最大值
4.  CAS操作修改同步状态值State成功

![clipboard.png][clipboard.png 4]

如果CAS操作失败，会调用**fullTryAcquireShared**方法，自旋修改State值：

![clipboard.png][clipboard.png 5]

ThreadA调用完**lock**方法后，等待队列结构如下：

![clipboard.png][clipboard.png 6]

> 此时：  
> 写锁数量：0  
> 读锁数量：1

## 3. ThreadB调用读锁的lock()方法 ##

由于读锁是共享锁，且此时写锁未被占用，所以此时ThreadB也可以拿到读锁：  
ThreadB调用完**lock**方法后，等待队列结构如下：

![clipboard.png][clipboard.png 6]

> 此时：  
> 写锁数量：0  
> 读锁数量：2

## 4. ThreadC调用写锁的lock()方法 ##

写锁其实是一种独占锁，实现了AQS的独占功能API，可以看到写锁的内部就是调用了AQS的acquire方法，该方法前面几章我们已经见过太多次了：

![clipboard.png][clipboard.png 7]

关键来看下ReentrantReadWriteLock是如何实现**tryAcquire**方法的，并没有什么特别，就是区分了两种情况：

1.  当前线程已经持有写锁
2.  写锁未被占用

![clipboard.png][clipboard.png 8]

ThreadC调用完lock方法后，由于存在使用中的读锁，所以会调用**acquireQueued**并被加入等待队列，这个过程就是独占锁的请求过程（[AQS\[二\]][AQS]），等待队列结构如下：

![clipboard.png][clipboard.png 9]

> 此时：  
> 写锁数量：0  
> 读锁数量：2

## 5. ThreadD调用读锁的lock()方法 ##

这个过程和ThreadA和ThreadB几乎一样，读锁是共享锁，可以重复获取，但是有一点区别：  
由于等待队列中已经有其它线程（ThreadC）排在当前线程前，所以**readerShouldblock**方法会返回true，这是公平策略的含义。

![clipboard.png][clipboard.png 10]

虽然获取失败了，但是后续调用**fullTryAcquireShared**方法，自旋修改State值，正常情况下最终修改成功，代表获取到读锁：

![clipboard.png][clipboard.png 11]

最终等待队列结构如下：

![clipboard.png][clipboard.png 9]

> 此时：  
> 写锁数量：0  
> 读锁数量：3

### 6. ThreadA释放读锁 ###

内部就是调用了AQS的**releaseShared**方法，该方法前面几章我们已经见过太多次了：

![clipboard.png][clipboard.png 12]

![clipboard.png][clipboard.png 13]

关键来看下ReentrantReadWriteLock是如何实现**tryReleaseShared**方法的，没什么特别的，就是将读锁数量减1：

![clipboard.png][clipboard.png 14]

**注意：**`HoldCounter`是个内部类，通过与`ThreadLocal`结合使用保存每个线程的持有读锁数量，其实是一种优化手段。

![clipboard.png][clipboard.png 15]

> 此时：  
> 写锁数量：0  
> 读锁数量：2

### 7. ThreadB释放读锁 ###

和ThreadA的释放完全一样，此时：

> 写锁数量：0  
> 读锁数量：1

### 8. ThreadD释放读锁 ###

和ThreadA的释放几乎一样，不同的是此时读锁数量为0，**tryReleaseShared**方法返回true：

![clipboard.png][clipboard.png 16]

> 此时：  
> 写锁数量：0  
> 读锁数量：0

![clipboard.png][clipboard.png 17]

因此，会继续调用**doReleaseShared**方法，**doReleaseShared**方法之前在讲[AQS\[四\]][AQS 1]时已经阐述过了，就是一个自旋操作：

![clipboard.png][clipboard.png 18]

该操作会将ThreadC唤醒：

![clipboard.png][clipboard.png 19]

### 9. ThreadC从原阻塞处继续向下执行 ###

ThreadC从原阻塞处被唤醒后，进入下一次自旋操作，然后调用**tryAcquire**方法获取写锁成功，并从队列中移除:

![clipboard.png][clipboard.png 20]

等待队列最终状态：

![clipboard.png][clipboard.png 21]

> 此时：  
> 写锁数量：1  
> 读锁数量：0

### 10. ThreadC释放写锁 ###

其实就是独占锁的释放，在[AQS\[二\]][AQS]中，已经阐述过了，不再赘述。

> 补充一点：如果头结点后面还有等待的共享结点，会以传播的方式依次唤醒，这个过程就是共享结点的唤醒过程，并无区别。

![clipboard.png][clipboard.png 22]

## 四、总结 ##

本章通过ReentrantReadWriteLock的公平策略，分析了RRW的源码，非公平策略分析方法也是一样的，非公平和公平的最大区别在于写锁的获取上：

![clipboard.png][clipboard.png 23]

在非公平策略中，写锁的获取永远不需要排队，这其实时性能优化的考虑，因为大多数情况写锁涉及的操作时间耗时要远大于读锁，频次远低于读锁，这样可以防止写线程一直处于饥饿状态。

关于ReentrantReadWriteLock，最后有两点规律需要注意：

1.  当RRW的等待队列队首结点是共享结点，说明当前写锁被占用，当写锁释放时，会以传播的方式唤醒头结点之后紧邻的各个共享结点。
2.  当RRW的等待队列队首结点是独占结点，说明当前读锁被使用，当读锁释放归零后，会唤醒队首的独占结点。

ReentrantReadWriteLock的特殊之处其实就是用一个int值表示两种不同的状态（低16位表示写锁的重入次数，高16位表示读锁的使用次数），并通过两个内部类同时实现了AQS的两套API，核心部分与共享/独占锁并无什么区别。

[clipboard.png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXNU?x-oss-process=image/format,png
[clipboard.png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXNV?x-oss-process=image/format,png
[clipboard.png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXNZ?x-oss-process=image/format,png
[clipboard.png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXMz?x-oss-process=image/format,png
[clipboard.png 4]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXM5?x-oss-process=image/format,png
[clipboard.png 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXRi?x-oss-process=image/format,png
[clipboard.png 6]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXRq?x-oss-process=image/format,png
[clipboard.png 7]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXRB?x-oss-process=image/format,png
[clipboard.png 8]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXRF?x-oss-process=image/format,png
[AQS]: https://blog.csdn.net/qq_32252917/article/details/103478031
[clipboard.png 9]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXRT?x-oss-process=image/format,png
[clipboard.png 10]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXRZ?x-oss-process=image/format,png
[clipboard.png 11]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXZh?x-oss-process=image/format,png
[clipboard.png 12]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXZt?x-oss-process=image/format,png
[clipboard.png 13]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXZy?x-oss-process=image/format,png
[clipboard.png 14]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXZz?x-oss-process=image/format,png
[clipboard.png 15]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXZC?x-oss-process=image/format,png
[clipboard.png 16]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXZZ?x-oss-process=image/format,png
[clipboard.png 17]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXY2?x-oss-process=image/format,png
[AQS 1]: https://segmentfault.com/a/1190000015807573
[clipboard.png 18]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXA1?x-oss-process=image/format,png
[clipboard.png 19]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXdD?x-oss-process=image/format,png
[clipboard.png 20]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXdN?x-oss-process=image/format,png
[clipboard.png 21]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXdW?x-oss-process=image/format,png
[clipboard.png 22]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXc4?x-oss-process=image/format,png
[clipboard.png 23]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWdtZW50ZmF1bHQuY29tL2ltZy9iVmJldXhr?x-oss-process=image/format,png