多线程之美7一ReentrantReadWriteLock源码分析
目录
前言
在多线程环境下，为了保证线程安全， 我们通常会对共享资源加锁操作，我们常用Synchronized关键字或者ReentrantLock 来实现，这两者加锁方式都是排他锁，即同一时刻最多允许一个线程操作，然而大多数场景中对共享资源读多于写，那么存在线程安全问题的是写操作（修改，添加，删除），我们是否应该考虑将读和写两个分开，只要运用合理，并发性能是不是可以提高，吞吐量增大呢？ ReentrantReadWriteLock已经为我们实现了这种机制，我们一起来看它是怎样实现的吧！
1、读写锁的一些概念
在查看可重入读写锁的源码前，有几个概念需要先知道，对于后面理解源码很有帮助。
1、ReentrantReadWriteLock 内部 Sync类依然是继承AQS实现的，因此同步状态字段 state，依然表示对锁资源的占用情况。那么如何实现一个 int类型的state 同时来表示读写锁两种状态的占用情况呢? 这里实现非常巧妙，将4个字节的int类型, 32位拆分为2部分，高16位表示读锁的占用情况，低16位表示写锁的占用情况，这样读写锁互不影响，相互独立；也因此读写锁的最大值是2^16-1 = 65535，不能超过16位，下面源码有体现。
state值表示如图所示：
2、读锁是共享锁，只要不超过最大值，可多个线程同时获取; 写锁是排他锁，同一时刻最多允许一个线程获取。
写锁与其他锁都互斥，含写写互斥，写读互斥，读写互斥。
3、state可同时表示读写锁的状态，state的高16位表示获取读锁的线程数，读锁支持可重入，即一个线程也可多次获取读锁，怎么维护每个读锁线程的重入次数的？ 每个线程有一个计数器 HoldCounter，用ThreadLocal来存放每个线程的计数器；state的低16位表示写锁的同步状态，因为写锁是排他锁，这里就不能表示获取写锁的线程数了，只能表示写锁的重入次数，获取写锁的线程可多次重复获取写锁（支持重入）。
读锁的计数器的实现原理如下：
可见ThreadLocalHoldCounter继承 ThreadLocal，每个获取读锁的线程是通过其本地变量来存储自己的计数器，来统计获取读锁的重入次数。ThreadLocal原理解析
static final class ThreadLocalHoldCounter
extends ThreadLocal<HoldCounter> {
//重写了ThreadLocal的initialValue方法
public HoldCounter initialValue() {
return new HoldCounter();
}
}4、state的高16位需要记录获取读锁的线程数，每增加一个线程获取读锁，在state的高16执行加1操作，即state+2^16，写锁增加重入次数，直接 state+1即可。
5、锁降级：获取写锁的线程，可以再次获取到读锁，即写锁降级为读锁。
? 读锁可以升级为写锁吗？ 不可以，因为存在线程安全问题，试想获取读锁的线程有多个，其中一个线程升级为写锁，对临界区资源进行操作，比如修改了某个值，对其他已经获取读锁的线程不可见，出现线程安全问题。
代码演示：
1、读写状态
AQS（AbstractQueuedSynchronizer的简称）中同步状态字段 private volatile int state, int类型，4个字节，32位，拆分为高16位表示读状态，低16位表示写状态，如下定义了一些常量，实现获取读写锁的数量。
ReentrantReadWriteLock部分代码如下：
//分隔位数，16位
static final int SHARED_SHIFT = 16;
//读锁加1的数量，1左位移16位， （16）0x10000 = (2)1000000000000000= (10) 65536
static final int SHARED_UNIT = (1 << SHARED_SHIFT);
//读写锁的最大数量， (16)0xFFFFFFFF =(2)1111111111111111 =(10)65535
static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1;
//写锁的掩码，用于计算写锁重入次数时，将state的高16全部置为0, 等于(2)1111111111111111
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
//获取读锁数，表示当前有多少个线程获取到读锁
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
//获取写锁重入次数（不等于0表示有线程持有独占锁，大于1,表示写锁有重入）
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }分别看一下获取读写锁数量的方法。
获取占用读锁的线程数，代码如下：
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }传入的c为 state，state 无符号右移16位，抹去低16位值，左边补0
示例图如下：
获取写锁的值的方法
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }与运算，将高16全部置为0，低16值代表写锁的值,&运算，相同为1，不同为0，得到低16位写锁值。
示例图如下：
2、三个锁概念
- int c =getState() ,获取state的值，代表同步锁状态，该值包含读写两个锁的同步状态
- int w = exclusiveCount(c); w代表写锁的同步状态，通过c获取到写锁的状态值
- int r = sharedCount(c); r 代表读锁的同步状态，通过c获取到读锁的状态值
以下分析三种情况下state，r, w 的值及代表的含义：
- 1、一个线程获取到写锁：
state =1, w =1, r =0
获取写锁加1操作就比较简单了，因为写锁是独占锁，与正常的ReentrantLock获取锁实现一样，占用state的低16位表示，不用看state的高16，左边补16位0。获取写锁一次，直接 c+1;
- 2、一个线程获取到读锁：
state =65536, w= 0, r=1
c初始为0 ,获取读锁，则读锁数量+1,执行 c + SHARED_UNIT, SHARED_UNIT = (2)1000000000000000 = （10）65536，括号内表示进制，SHARED_UNIT是每次读锁加1的数值。
如下图所示: 在获取读锁数量 r时，将state的低16位抹去，r=1，而state此时的值= 2^16 =65536，state的实际值可能会很大，但其实分别拆分读写锁的值不一定大，只是读锁值表示在高位，会造成state值很大。
- 3、一个线程获取到写锁，又获取到读锁情况（锁降级):
state = 65537,w=1, r=1
state二进制表示： 00000000 00000001 00000000 00000001
锁降级代码演示如下：
package readwritelock;
import java.util.concurrent.locks.ReentrantReadWriteLock;
/**
* @author zdd
* 2019/12/30 上午
* Description: 锁降级测试
*/
public class ReadWriteLockTest {
static Integer shareVar = 0;
public static void main(String[] args) {
ReentrantReadWriteLock rw = new ReentrantReadWriteLock();
//1，首先获取写锁
rw.writeLock().lock();
//2.修改共享变量值
shareVar = 10 ;
//3.再获取读锁
rw.readLock().lock();
System.out.println("读取变量值 shareVar："+ shareVar);
//4.释放写锁
rw.writeLock().unlock();
//5.释放读锁
rw.readLock().unlock();
}
}2、类结构和构造方法
ReentrantReadWriteLock 类中有ReadLock和WriteLock,分别对应读锁和写锁，而读写锁又分为公平方式和非公平方式获取锁。
简略类图结构如下：
构造方法如下：根据传入参数设置公平或者非公平获取锁方式，默认是非公平方式
public ReentrantReadWriteLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
readerLock = new ReadLock(this);
writerLock = new WriteLock(this);
}3、写锁
由于写锁是独占锁，由于写锁是独占锁，获取写锁的方式在AQS中已经说过了，详见AQS源代码分析, 只是每个子类的尝试获取锁方式不同，所以ReentrantReadWriteLock类获取写锁过程就看一下尝试获取锁方法的源码。
3.1、尝试获取锁
tryAcquire（int acquires),获取锁失败则加入同步队列中等待获取锁，源代码如下：
protected final boolean tryAcquire(int acquires) {
Thread current = Thread.currentThread();
//1,获取同步状态state的值，注意该值可表示读写锁的同步状态
int c = getState();
//2,获取写锁状态，低16位的值
int w = exclusiveCount(c);
//3,如果同步锁状态不为0，有线程已经获取到了锁
if (c != 0) {
//4,w==0则表示写锁为0，那么一定有线程获取了读锁，需要等待，读写互斥
//current != getExclusiveOwnerThread() 当前线程不等于已经获取到写锁的线程，则也需等待其释放，写写互斥
if (w == 0 || current != getExclusiveOwnerThread())
return false;
//5，此时再次获取锁，判断锁重入次数是否超过最大限定次数
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
//更新写锁重入次数
setState(c + acquires);
return true;
}
//6,代码执行这，一定是c==0,同步锁空闲情况
//writerShouldBlock该方法是基于公平锁和非公平锁2种方式的体现
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
//获取到锁,设置独占锁为当前写锁线程
setExclusiveOwnerThread(current);
return true;
}写锁是否应该阻塞等待
- 1、 非公平锁方式
final boolean writerShouldBlock() {
//直接返回false
return false; // writers can always barge
}- 2、公平锁方式
需要判断同步队列中是否还有其他线程在挂起等待，如存在应该按照入队顺序获取锁
final boolean writerShouldBlock() {
return hasQueuedPredecessors();
}public final boolean hasQueuedPredecessors() {
//1.获取同步队列头，尾节点
Node t = tail;
Node h = head;
Node s;
// h !=t 同步队列不为空
// 队列中还有其他线程在等待锁，则返回true
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}3.2、释放写锁
unlock方法释放锁
public void unlock() {
sync.release(1);
}可见，调用内部类Sync的release方法，Sync继承AQS
public final boolean release(int arg) {
if (tryRelease(arg)) {
//1,释放锁成功
Node h = head;
if (h != null && h.waitStatus != 0)
//2.唤醒同步队列中等待线程
unparkSuccessor(h);
return true;
}
return false;
}核心在尝试释放锁方法上，看看写锁的释放锁方法tryRelease
protected final boolean tryRelease(int releases) {
//1,判断当前线程是否持有当前锁
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
//2,同步状态 - 需要释放的写锁同步值
int nextc = getState() - releases;
boolean free = exclusiveCount(nextc) == 0;
if (free)
//3,free ==true,完全释放写锁，将当前获取独占锁线程置空
setExclusiveOwnerThread(null);
//4,更新state值
setState(nextc);
return free;
}注： 在释放写锁占用次数时, state的高16的读锁有值也不影响，减去releases，首先减去的state低位的数，而且在释放写锁时，state的低16位的值一定>=1，不存在减少读锁的值情况。
int nextc = getState() - releases; boolean free = exclusiveCount(nextc) == 0;
也可改写为如下面代码
//1,获取state值 int c = getState(); //2,获取写锁的值 int w= exclusiveCount(c); int remain = w- releases; boolean free = remain== 0;
4、读锁
4.1、获取读锁
读锁调用lock方法加锁，实际调用Sync的acquireShared方法
public void lock() {
sync.acquireShared(1);
}走进acquireShared，获取共享锁方法
public final void acquireShared(int arg) {
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}尝试获取锁tryAcquireShared，如果返回值<0, 表示获取读锁失败
主要执行步骤：
1、首先判断是否存在其他线程在占用写锁，有需要挂起等待；
2、在不用阻塞等待，且读锁值没有超过最大值，cas更新成功了state的值，可以获取到读锁，还会做以下事：
? a. 第一个获取读锁的，直接记录线程对象和其重入获取读锁的次数
? b. 非第一个获取读锁的，则获取缓存计数器（cachedHoldCounter），其记录上一次获取读锁的线程，如果是同一个线程，则直接更新其计数器的重入次数，如果缓存计数器为空或缓存计数器的线程不是当前获取读锁的线程，则从当前线程本地变量中获取自己的计数器，更新计数器的值
protected final int tryAcquireShared(int unused) {
//1,获取当前线程对象
Thread current = Thread.currentThread();
//2,获取同步锁的值
int c = getState();
/*3,exclusiveCount(c) != 0 计算写锁的同步状态，不等于0，说明有写锁已经获取到同步锁，
*需要判断当前线程是否等于获取写锁线程，
*是，可以允许再次获取读锁，这里涉及到锁降级问题，写锁可以降为读锁
*否则不让获取，写读互斥
*/
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return -1;
//4,获取读锁同步状态
int r = sharedCount(c);
/**
*此处3个判断条件
* 1.是否应该阻塞等待，这里也是基于公平锁和非公平获取锁实现
* 2.读锁同步状态值是超过最大值,即限制获取读锁的最大线程数
* 3.cas更新读锁同步状态是否成功
*/
if (!readerShouldBlock() &&
r < MAX_COUNT &&
compareAndSetState(c, c + SHARED_UNIT)) {
//可以获取到读锁
//r==0表示是第一个获取读锁的线程
if (r == 0) {
firstReader = current;
//记录第一个线程读锁的重入次数
firstReaderHoldCount = 1;
} else if (firstReader == current) {
//是第一个获取读锁线程，锁重入，锁重入次数+1
firstReaderHoldCount++;
} else {
// 已有其他线程获取到读锁
/*
*1,获取缓存记录的计数器，计数器是用来统计每一个获取读锁线程的重入次数的，
*由每个线程的ThreadLocal,即线程内的副本存储，相互独立；
*此处也不是放入缓存，在有多个线程同时获取读锁情况，
*用一个变量记录上一个获取读锁的线程的计数器，可能考虑多次获取读锁线程大概率是同一个线程情况，
*这样做是可提高执行效率
*/
HoldCounter rh = cachedHoldCounter;
// rh==null,第一个获取读锁，rh没有值
// 或者计数器存储的上一次线程的id与当前线程不等， 即不是相同一个线程，
//那么就获取当前线程内部的计数器，并赋值给cachedHoldCounter变量，这样可以让下一次获取读锁线程获取比较了
if (rh == null || rh.tid != getThreadId(current))
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0)
/*进入该条件，我理解是在线程获取读锁再释放后，同一线程再次获取读锁情况，
* 缓存计数器会记录上一个线程计数器，因为线程释放读锁后，count=0，
* 这里重新将计数器放入线程内部中，
* 因为线程在使用完线程内部变量后会防止内存泄漏，会执行remove,释放本地存储的计数器。
*/
readHolds.set(rh);
//计数器+1
rh.count++;
}
return 1;
}
//上面3个条件没有同时满足，没有成功获取到读锁，开始无限循环尝试去获取读锁
return fullTryAcquireShared(current);
}无限循环尝试获取共享锁 fullTryAcquireShared方法
主要执行步骤：
1、 如果有其他线程获取到了写锁，写读互斥，应该去挂起等待；
2、如果可以获取读锁，判断是否应该阻塞等待，在公平获取锁方式中，同步队列中有其他线程在等待，则应该去排队按照FIFO顺序获取锁，非公平获取锁方式，可以直接去竞争获取锁。
3、可以获取锁，则尝试cas更新state的值，更新成功，获取到锁。
final int fullTryAcquireShared(Thread current){
HoldCounter rh = null;
//无限循环
for (;;) {
//获取同步锁状态
int c = getState();
//判断写锁值不为0，且不是当前线程，不可获取读锁
if (exclusiveCount(c) != 0) {
if (getExclusiveOwnerThread() != current)
return -1;
} else if (readerShouldBlock()) {
//没有线程获取到写锁情况，公平获取锁情况，
//同步队列中有其他线程等待锁，该方法主要是在需要排队等待，计数器重入次数==0情况，清除计数器
if (firstReader == current) {
//此处firstReader !=null, 则第1个获取读锁的线程还没释放锁，可允许该线程继续重入获取锁
//计数器count一定>0
} else {
if (rh == null) {
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current)) {
rh = readHolds.get();
if (rh.count == 0)
//清除计数器
readHolds.remove();
}
}
// 为什么rh.count == 0就不让线程获取到锁了，基于公平获取锁方式，去同步队列中等待
if (rh.count == 0)
return -1;
}
}
//获取读锁线程超过最大限制值 65535
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// cas执行读锁值+1
if (compareAndSetState(c, c + SHARED_UNIT)) {
if (sharedCount(c) == 0) {
//1,第一个获取读锁
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
//2,第一个获取读锁重入
firstReaderHoldCount++;
} else {
//3,非第一个线程获取读锁，存在多个线程获取读锁
if (rh == null)
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
//缓存计数器变量记录此次获取读锁线程的计数器
cachedHoldCounter = rh; // cache for release
}
return 1;
}
}
}tryAcquireShared 返回< 0, 获取锁失败，执行 doAcquireShared
在获取读锁失败后，执行以下步骤：
1、将节点加入同步队列中
2、如果前置节点是头节点，将再次尝试获取锁，如果成功，设置当前节点为head节点，并根据tryAcquireShared方法的返回值r判断是否需要继续唤醒后继节点，如果 r大于0，需要继续唤醒后继节点，r=0不需要唤醒后继节点。
3、如果前置节点不是头节点，则在队列中找到安全位置，设置前置节点 ws=SIGNAL, 挂起等待。
private void doAcquireShared(int arg) {
final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head) {
//如果前继节点是头节点，再次尝试获取共享锁
int r = tryAcquireShared(arg);
//r>=0,表示获取到锁,
//r=0,表示不需要唤醒后继节点
//r>0,需要继续唤醒后继节点
if (r >= 0) {
//该方法实现2个步骤
//1,设置当前节点为头节点
//2,r>0情况会继续唤醒后继节点
setHeadAndPropagate(node, r);
//旧的头节点移出队列
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}setHeadAndPropagate 该方法是与独占锁获取锁的区别之处，获取到锁后，设置为头结点还需要继续传播下去。
private void setHeadAndPropagate(Node node, int propagate) {
//记录是的旧的头节点
Node h = head; // Record old head for check
//设置当前获取到锁节点为头节点
setHead(node);
//propagate >0,表示还需要继续唤醒后继节点
//旧的头节点和新头节点为空，或者ws<0,满足条件之一，尝试去唤醒后继节点
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
//后继节点为空或者是共享节点（获取读锁的线程）
if (s == null || s.isShared())
doReleaseShared();
}
}doReleaseShared 方法较难理解，在释放锁中也有调用，留着后面一起分析。
4.2、释放读锁
public void unlock() {
sync.releaseShared(1);
}AQS中释放共锁方法releaseShared
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}看一下读写锁具体实现tryReleaseShared 的方法
protected final boolean tryReleaseShared(int unused) {
Thread current = Thread.currentThread();
//1,更新或者移出线程内部计数器的值
if (firstReader == current) {
//当前线程是第一个获取读锁的线程
if (firstReaderHoldCount == 1)
//直接置空
firstReader = null;
else
//该线程获取读锁重入多次，计数器-1
firstReaderHoldCount--;
} else {
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
int count = rh.count;
if (count <= 1) {
//非第一个获取读锁线程，避免ThreadLocal内存泄漏，移出计数器
readHolds.remove();
if (count <= 0)
//此处是调用释放锁次数比获取锁次数还多情况，直接抛异常
throw unmatchedUnlockException();
}
--rh.count;
}
//2,循环cas更新同步锁的值
for (;;) {
int c = getState();
//读锁同步状态-1
int nextc = c - SHARED_UNIT;
if (compareAndSetState(c, nextc))
// Releasing the read lock has no effect on readers,
// but it may allow waiting writers to proceed if
// both read and write locks are now free.
//返回完全释放读锁，读锁值是否==0,完全释放，等待写锁线程可获取
return nextc == 0;
}
}tryReleaseShared 返回true情况，表示完全释放读锁，执行doReleaseShared，那就需要唤醒同步队列中等待的其他线程
在读写锁中存在几种情况
情况一、如果当前获取锁的线程占用的是写锁，则后来无论是获取读锁还写锁的线程都会被阻塞在同步队列中，
同步队列是FIFO队列，在占用写锁的释放后，node1获取读锁，因读锁是共享的，继续唤醒后一个共享节点。
如上图，在node1获取到读锁时，会调用doReleaseShared方法，继续唤醒下一个共享节点node2,可以持续将唤醒动作传递下去，如果node2后面还存在几个等待获取读锁的线程，这些线程是由谁唤醒的？是其前置节点，还是第一个获取读锁的节点？ 应该是第1个获取锁的节点，这里即node1, 由下代码可见，在无限循环中，只有头节点没有变化时，即再没其他节点获取到锁后，才会跳出循环。
private void doReleaseShared() {
for (;;) {
//获取同步队列中头节点
Node h = head;
//同步队列中节点不为空，且节点数至少2个
if (h != null && h != tail) {
int ws = h.waitStatus;
//1,表示后继节点需要被唤醒
if (ws == Node.SIGNAL) {
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue; // loop to recheck cases
//唤醒后继节点
unparkSuccessor(h);
}
//2,后继节点暂时不需要唤醒，设置节点 ws = -3, 确保后面可以继续传递下去
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue; // loop on failed CAS
}
//如果头节点发生变化，表示已经有其他线程获取到锁了，需要重新循环，确保可以将唤醒动作传递下去。
if (h == head) // loop if head changed
break;
}
}5、思考
1、在非公平获取锁方式下，是否存在等待获取写锁的线程始终获取不到锁，每次都被后来获取读锁的线程抢先，造成饥饿现象？
存在这种情况，从获取读锁源码中看出，如果第一个线程获取到读锁正在执行情况下，第二个等待获取写锁的线程在同步队列中挂起等待，在第一个线程没有释放读锁情况下，又陆续来了线程获取读锁，因为读锁是共享的，线程都可以获取到读锁，始终是在读锁没有释放完毕加入获取读锁的线程，那么等待获取写锁的线程是始终拿不到写锁，导致饥饿。为什么默认还是非公平模式？因为减少线程的上下文切换，保证更大的吞吐量。
6、总结
1、读写锁可支持公平和非公平两种方式获取锁。
2、支持锁降级，写锁可降级为读锁，但读锁不可升级为写锁。
3、大多数场景是读多于写的，所以ReentrantReadWriteLock 比 ReentrantLock（排他锁）有更好的并发性能和吞吐量。
4、读写锁中读锁和写锁都支持锁重入。
5、在获取Condition对象实现阻塞唤醒机制,ReentrantReadWriteLock.WriteLock 重写了 newCondition方法，ReadLock不支持，即读锁不支持与Condition配合使用，使用阻塞唤醒机制。