【JDK1.8源码阅读】ReentrantReadWriteLock源码实现分析整理（八）

最新推荐文章于 2022-03-19 17:26:18 发布

jeanheo

最新推荐文章于 2022-03-19 17:26:18 发布

阅读量264

点赞数

分类专栏： JDK源码 JDK1.8 源码阅读文章标签： JDK源码

本文链接：https://blog.csdn.net/qwe6112071/article/details/87446025

版权

JDK1.8 源码阅读同时被 2 个专栏收录

9 篇文章 5 订阅

订阅专栏

JDK源码

8 篇文章 0 订阅

订阅专栏

文章目录

ReentrantReadWriteLock基本原理分析
Sync 队列同步组件基础实现

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默认值为可以标识当前线程的空计数对象。

和这两个内部类关联的有4个成员变量：

/**
 * 保存当前线程重入读锁的次数的容器。在读锁重入次数为 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));
}

下面主要关注tryLock()和lock()实现，lockInterruptibly()和tryLock(long timeout, TimeUnit unit)直接调用了队列同步器抽象类中实现的基础方法，可参考前面文章，这里不再分析。

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)方法，整体的操作步骤为：

判断是否存在读锁，或者存在写锁，但不是本线程持有，则返回获取失败
如果存在写锁，为本线程持有，则进入重入累加，需要先判断是否移除最大值
不存在锁，则用cas尝试获取锁，失败说明存在其他线程并发获取锁，返回失败
如果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 写锁释放

写锁的释放操作过程：

先判断锁是否被当前线程持有，如果不是，抛出IllegalMonitorStateException异常
减去锁重入次数，判断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中，在以下几种情况，获取读锁会失败：

有线程持有写锁，且该线程不是当前线程，获取锁失败。
写锁空闲且公平策略决定读线程应当被阻塞，除了重入获取，其他获取锁失败。
读锁数量达到最多，抛出异常。

除了以上三种情况，该线程会调用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;
    }
}

以上是可重入读写锁的核心实现细节，关于ReadLock、WriteLock的定义以及ReentrantReadWriteLock本身提供的众多工具方法，实现较为简单，感兴趣的读者可以直接通过阅读源码了解。

jeanheo

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
【JDK1.8源码阅读】ReentrantReadWriteLock源码实现分析整理（八）

ReentrantReadWriteLock基本原理分析像ReentrantLock实现的是一个排他锁，即若有一个线程获取锁，其他线程都不能再次获取。而ReentrantReadWriteLock提供了一种共享锁策略，即如果有线程获取的是共享锁，则其他线程可以继续获取共享锁，但不能获取排他锁；而如果当前线程获取了排他锁，则其他线程共享锁和排他锁都不能获取。基于ReentrantReadWrit...
复制链接

扫一扫

专栏目录