本文深入解析ReentrantReadWriteLock的工作原理，介绍了其读写锁机制，包括读写锁的获取、释放以及公平策略。重点剖析了读写状态维护、重入计数和锁降级等内容，帮助理解如何提高多线程读写并发性能。
一.ReentrantReadWriteLock基本原理分析
像ReentrantLock实现的是一个排他锁，即若有一个线程获取锁，其他线程都不能再次获取。而ReentrantReadWriteLock提供了一种共享锁策略，即如果有线程获取的是共享锁，则其他线程可以继续获取共享锁，但不能获取排他锁；而如果当前线程获取了排他锁，则其他线程共享锁和排他锁都不能获取。
基于ReentrantReadWriteLock内部实现了一对读写锁，一般情况下，读写锁的性能都会比排它锁好，因为大多数场景读是多于写的。在读多于写的情况下，读写锁能够提供比排它锁更好的并发性和吞吐量。
ReentrantReadWriteLock实现了ReadWriteLock接口，ReadWriteLock接口定义非常简洁：
public interface ReadWriteLock {
/**
* Returns the lock used for reading.
*
* @return the lock used for reading
*/
Lock readLock();
/**
* Returns the lock used for writing.
*
* @return the lock used for writing
*/
Lock writeLock();
}
在ReentrantReadWriteLock里，这两个方法的实现也非常简单，下面抽出ReentrantReadWriteLock相关源码定义：
public class ReentrantReadWriteLock
implements ReadWriteLock, java.io.Serializable {
private static final long serialVersionUID = -6992448646407690164L;
/** 读锁对象引用 */
private final ReentrantReadWriteLock.ReadLock readerLock;
/** 写锁对象引用 */
private final ReentrantReadWriteLock.WriteLock writerLock;
/** 同步队列组件，可能是公平或非公平的队列同步器 */
final Sync sync;
/**
* 默认初始化一个非公平读写锁
*/
public ReentrantReadWriteLock() {
this(false);
}
/**
* 根据传入fair创建公平或非公平队列同步器，同时初始化读写锁对象。
*/
public ReentrantReadWriteLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
readerLock = new ReadLock(this);
writerLock = new WriteLock(this);
}
// 返回初始好的写锁
public ReentrantReadWriteLock.WriteLock writeLock() { return writerLock; }
// 返回初始号的读锁
public ReentrantReadWriteLock.ReadLock readLock() { return readerLock; }
除了当前基础定义，ReentrantReadWriteLock类中还定义了许多工具方法，这个放在最后分析。下面主要看看ReentrantReadWriteLock如何实现具体的锁特性。
ReentrantReadWriteLock提供了5个内部类来辅助实现相关读写特性，这些类的关系如下图：
类似于ReentrantLock，ReentrantReadWriteLock基于Sync、NonfairSync、FairSync等内部类来实现公平、非公平锁的逻辑，而两个具体的读写锁类ReadLock、WriteLock主要借助Sync等相关同步器来实现加解锁。
Sync 队列同步组件基础实现
Sync内部类设计
在Sync内部，定义了两个内部类：HoldCounter、ThreadLocalHoldCounter。其中HoldCounter主要与读锁配套使用，HoldCounter源码如下：
// 计数器
static final class HoldCounter {
// 计数
int count = 0;
// 获取当前线程的TID属性的值
final long tid = getThreadId(Thread.currentThread());
}
HoldCounter主要有两个属性，count和tid，用tid来唯一标识某个特定读线程，再根据count表示该个读线程重入的次数。
再看ThreadLocalHoldCounter实现:
// 本地线程计数器
static final class ThreadLocalHoldCounter
extends ThreadLocal<HoldCounter> {
// 重写初始化方法，在没有进行set的情况下，获取的都是该HoldCounter值
public HoldCounter initialValue() {
return new HoldCounter();
}
}
ThreadLocalHoldCounter继承自ThreadLocal，重写了其内部的initialValue，即相对于ThreadLocal默认值为null，ThreadLocalHoldCounter默认值为可以标识当前线程的空计数对象。
/**
* 保存当前线程重入读锁的次数的容器。在读锁重入次数为 0 时移除。
*/
private transient ThreadLocalHoldCounter readHolds;
/**
* 最近一个成功获取读锁的线程的计数。这省却了ThreadLocal 查找，
* 通常情况下，下一个释放线程是最后一个获取线程。这不是 volatile 的，
* 因为它仅用于试探的，线程进行缓存也是可以的
* （因为判断是否是当前线程是通过线程id来比较的）。
*/
private transient HoldCounter cachedHoldCounter;
/**
* firstReader是这样一个特殊线程：它是最后一个把 共享计数 从 0 改为 1 的
* （在锁空闲的时候），而且从那之后还没有释放读锁的。如果不存在则为null。
*
* firstReader 不能导致保留垃圾，因此在 tryReleaseShared 里设置为null，
* 除非线程异常终止，没有释放读锁。
*
* 作用是在跟踪无竞争的读锁计数时非常便利。
*
* firstReader及其计数firstReaderHoldCount是不会放入 readHolds 的。
*/
private transient Thread firstReader = null;
/**
* firstReaderHoldCount 是 firstReader 的重入计数。
*/
private transient int firstReaderHoldCount;
读写锁状态设计
在ReentrantLock中，我们用state来表示某个线程的重入次数，在ReentrantReadWriteLock中有所区别的是，用state同时维护了读写状态的重入次数，这里对于读状态，就不再限定在某个线程了。具体实现是安位切割了state变量，高16位用于存储读状态，低16位用于存储写状态，如下图所示： 我们可以简单判断：
如果state=0，说明不存在读写锁
如果state!=0，说明不能继续加写锁，可以进一步判断，如果state>>16>0，说明读锁被获取，可以加读锁。
在Sync类中，定义了一些基础属性和方法来计算读锁和写锁的加锁次数
abstract static class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = 6317671515068378041L;
// 16位偏移值，分割state高低读写数
static final int SHARED_SHIFT = 16;
// 复用于计算state,在直到读锁数基础上，可以复用当前常量计算出state
static final int SHARED_UNIT = (1 << SHARED_SHIFT);
// 表示每个锁的最大加锁次数
static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1;
// 表示写锁掩码
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
/** 计算返回入参代表的读锁数 */
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
/** 计算返回入参代表的写锁数 */
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
}
写锁的获取和释放
写锁是一个支持重进入的排它锁。如果当前线程已经获取了写锁，则增加写状态。如果当前线程在获取写锁时，读锁已经被获取（读状态不为0）或者该线程不是已经获取写锁的线程，则当前线程进入等待状态。 从WriteLock实现看，写锁加锁入口有lock()、lockInterruptibly()、tryLock()、tryLock(long timeout, TimeUnit unit)，下面看看这部分源码实现：
/**
* 堵塞获取写锁
*/
public void lock() {
sync.acquire(1);
}
/**
* 堵塞获取写锁，可被打断
*/
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
/**
* 非堵塞获取写锁，立即返回结果
*/
public boolean tryLock( ) {
return sync.tryWriteLock();
}
/**
* 在超时时间内堵塞获取写锁，可被打断。
*/
public boolean tryLock(long timeout, TimeUnit unit)
throws InterruptedException {
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}
tryWriteLock实现
tryLock()通过tryWriteLock源码实现：
final boolean tryWriteLock() {
// 获取当前线程
Thread current = Thread.currentThread();
// 获取状态值
int c = getState();
if (c != 0) { // 说明存在读锁或写锁
// 获取写锁加锁量
int w = exclusiveCount(c);
// 没有写锁，或者存在写锁，但不被当前线程持有
if (w == 0 || current != getExclusiveOwnerThread())
// 返回
return false;
// 到达最大加锁量，抛异常
if (w == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
}
// cas尝试加锁，失败说明有其他线程并发竞争到锁。如果本身c!=0，走到这一步说明已经被当前线程独占，不可能有其他线程并发修改c，只能是c=0时被其他线程并发修改
if (!compareAndSetState(c, c + 1))
// 返回获取失败
return false;
// 设置当前线程为独占线程
setExclusiveOwnerThread(current);
// 返回获取成功
return true;
}
acquire(int arg)实现
lock调用了Sync的抽象父类AbstractQueuedSynchronizer定义的acquire(int arg)方法，这里主要分析Sync类重写的在方法里调用到的tryAcquire(int acquires)方法，整体的操作步骤为：
1.判断是否存在读锁，或者存在写锁，但不是本线程持有，则返回获取失败
2.如果存在写锁，为本线程持有，则进入重入累加，需要先判断是否移除最大值
3.不存在锁，则用cas尝试获取锁，失败说明存在其他线程并发获取锁，返回失败
4.如果cas成功，则设置锁的独占线程为当前线程，返回成功。
protected final boolean tryAcquire(int acquires) {
// 获取当前线程
Thread current = Thread.currentThread();
// 获取状态
int c = getState();
// 写线程数量
int w = exclusiveCount(c);
if (c != 0) { // 存在锁
// 注意 c != 0 && w == 0 说明存在读锁
if (w == 0 || current != getExclusiveOwnerThread()) // 存在读锁或者存在写锁，但不是当前线程拿到锁，则返回失败
return false;
if (w + exclusiveCount(acquires) > MAX_COUNT) // 判断是否超过最高写线程数量
throw new Error("Maximum lock count exceeded");
// 设置AQS状态
setState(c + acquires);
// 加锁成功
return true;
}
// 走到这里说明c=0，不存在锁，且不是当前线程持有的写锁
// 判断是否进行堵塞，根据是否公平在子类实现
// 如果应该堵塞直接返回false,否则尝试cas
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires)) // 写线程是否应该被阻塞
return false;
// 设置独占线程
setExclusiveOwnerThread(current);
return true;
tryRelease 写锁释放
写锁的释放操作过程：
1.先判断锁是否被当前线程持有，如果不是，抛出IllegalMonitorStateException异常
2.减去锁重入次数，判断state是否为0，如果是，则进行真正释放锁操作，将独占线程设为空，且更新state=0，最后返回是否真正释放锁的标识
protected final boolean tryRelease(int releases) {
// 非本线程持有，抛异常
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
// 减重入次数
int nextc = getState() - releases;
// 判断写锁是否为0
boolean free = exclusiveCount(nextc) == 0;
// 为0则进行释放
if (free)
setExclusiveOwnerThread(null);
setState(nextc);
return free;
}
读锁的获取和释放
类似于写锁的加锁，读写依然有4种方式获取，这里主要看看在Sync中实现的两种获取方法。
tryReadLock实现
final boolean tryReadLock() {
Thread current = Thread.currentThread();
for (;;) {
int c = getState();
// 如果存在写锁且不是当前线程独占，则返回获取失败
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return false;
// 获取读锁数量
int r = sharedCount(c);
// 数量溢出
if (r == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// cas尝试加锁
if (compareAndSetState(c, c + SHARED_UNIT)) {
if (r == 0) { // 是否为第一个添加读锁线程
// 记录首个读锁线程和次数，面对firstReader的处理：firstReader是不会放到readHolds里的，这样，在读锁只有一个的情况下，就避免了查找readHolds
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) { // 否则如果已经是当前线程
// 累加首线程添加读锁数
firstReaderHoldCount++;
} else { // 当前线程不是第一个添加读锁线程
// 获取缓存计数器，表示最近一个成功获取读锁的线程的计数
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current)) // cachedHoldCounter 非当前线程计数器，即cachedHoldCounter不是最近一个获取读锁的线程的计数，应该更新为当前线程的计数器
// 更新为本地线程私有计数器，从readHolds中获取
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0) // 缓存计数器存在且为当前线程，但计数器数量为0，这种情况出现的可能是当前线程是最后一个获取、并释放了锁的线程，因而rh.count=0
// 这里可以理解为一个移除或重置操作，将本地私有的计数器次数设为0
readHolds.set(rh);
// 累加计数器持有锁数
rh.count++;
}
// 返回获取成功
return true;
}
}
}
tryAcquireShared实现
acquireShared(int arg)中会调用到tryAcquireShared，在Sync中实现，其他都是AQS原生实现，这里主要看tryAcquireShared如何获取读锁。
在tryAcquireShared中，在以下几种情况，获取读锁会失败：
1.有线程持有写锁，且该线程不是当前线程，获取锁失败。
2.写锁空闲且公平策略决定读线程应当被阻塞，除了重入获取，其他获取锁失败。
3.读锁数量达到最多，抛出异常。
4.除了以上三种情况，该线程会调用fullTryAcquireShared循环尝试获取读锁直到成功。
protected final int tryAcquireShared(int unused) {
Thread current = Thread.currentThread();
int c = getState();
// 有线程持有写锁，且该线程不是当前线程
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
// 返回负数表示获取失败
return -1;
// 获取读锁数
int r = sharedCount(c);
// 根据公平策略判定当前线程是否堵塞
// 不堵塞或堵塞到被唤醒后，如果读锁没移除，则用cas尝试获取锁
if (!readerShouldBlock() &&
r < MAX_COUNT &&
compareAndSetState(c, c + SHARED_UNIT)) {
if (r == 0) {
// 记录首个读锁线程和次数，面对firstReader的处理：firstReader是不会放到readHolds里的，这样，在读锁只有一个的情况下，就避免了查找readHolds
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
// 如果firstReader是当前，直接累加锁数
firstReaderHoldCount++;
} else { // 非 firstReader 读锁重入计数更新
// 获取缓存计数器，表示最近一个成功获取读锁的线程的计数
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current)) // cachedHoldCounter 非当前线程计数器，即cachedHoldCounter不是最近一个获取读锁的线程的计数，应该更新为当前线程的计数器
// 更新为本地线程私有计数器，从readHolds中获取
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0) // 缓存计数器存在且为当前线程，但计数器数量为0，这种情况出现的可能是当前线程是最后一个获取、并释放了锁的线程，因而rh.count=0
// 这里可以理解为一个移除或重置操作，将本地私有的计数器次数设为0
readHolds.set(rh);
// 累加计数器持有锁数
rh.count++;
}
// 返回大于0表示获取成功
return 1;
}
// 获取读锁失败，放到循环里重试。
return fullTryAcquireShared(current);
}
fullTryAcquireShared重试的代码如下所示：
final int fullTryAcquireShared(Thread current) {
HoldCounter rh = null;
for (;;) {
int c = getState();
if (exclusiveCount(c) != 0) {
if (getExclusiveOwnerThread() != current)
// 有线程持有写锁，且该线程不是当前线程，获取锁失败
return -1;
} else if (readerShouldBlock()) { // 不存在写锁，根据公平策略判定当前线程是否堵塞
// 下面的处理是说，如果是已获取读锁的线程重入读锁时，
// 即使公平策略指示应当阻塞也不会阻塞。否则，会导致死锁
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
} else {
if (rh == null) {
// 类似tryAcquireShared中实现
rh = cachedHoldCounter;
if (rh == null || rh.tid != current.getId()) {
rh = readHolds.get();
if (rh.count == 0)
readHolds.remove();
}
}
// 需要阻塞且是非重入(还未获取读锁的)，获取失败。
if (rh.count == 0)
return -1;
}
}
// 写锁空闲 且 公平策略决定线程可以获取读锁
if (sharedCount(c) == MAX_COUNT)// 读锁数量达到最多
throw new Error("Maximum lock count exceeded");
//7. 申请读锁成功，下面的处理跟tryAcquireShared是类似的。
if (compareAndSetState(c, c + SHARED_UNIT)) {
if (sharedCount(c) == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
if (rh == null)
rh = cachedHoldCounter;
if (rh == null || rh.tid != current.getId())
rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
cachedHoldCounter = rh; // cache for release
}
return 1;
}
}
}
从上面看到，当判断存在写锁时，线程不会马上返回获取失败，而会判断是否为当前线程获取到写锁，如果是当前线程获取了写锁，是可以添加读锁的，这是对锁降级的支持，在线程获取写锁后，可以继续获取读锁，而后释放写锁，就降级为读锁了。
releaseShared 读锁释放
读锁释放代码如下：
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}
其中doReleaseShared参考在AQS中实现，这里主要看看在Sync中实现的tryReleaseShared：
protected final boolean tryReleaseShared(int unused) {
Thread current = Thread.currentThread();
// 清理firstReader缓存 或 readHolds里的重入计数
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1)
firstReader = null;
else
firstReaderHoldCount--;
} else {
// 不是首线程，先看是否为缓存计数器（最近加锁的计数器）
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != current.getId())
// 不是，从本地线程私有计数器里获取
rh = readHolds.get();
// 获取本线程的锁重入数
int count = rh.count;
// 判断是否可以完全释放读锁
if (count <= 1) {
// 完全释放读锁
readHolds.remove();
// 状态异常
if (count <= 0)
throw unmatchedUnlockException();
}
--rh.count; // 主要用于重入退出
}
// 循环在CAS更新状态值，主要是把读锁数量减 1，上 main不需要是因为修改操作没有并发可能性。
for (;;) {
int c = getState();
// 减少的值是1<<16
int nextc = c - SHARED_UNIT;
if (compareAndSetState(c, nextc))
// 释放读锁对其他读线程没有任何影响，
// 但可以允许等待的写线程继续，如果读锁、写锁都空闲。
return nextc == 0;
}
}
扫一扫
2187
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
