Java 锁系列（五）——ReentrantReadWriteLock源码分析

已于 2023-03-09 16:31:08 修改
阅读量450 收藏
点赞数
分类专栏： Java与JVM 分布式与高并发 文章标签： java 锁
于 2021-11-18 09:11:21 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/nineya_com/article/details/121392943
版权

一、ReentrantReadWriteLock概述

ReentrantReadWriteLock 是读写锁的实现，读锁可以在没有写锁的时候被多个线程同时持有，写锁就是和 ReentrantLock 类似的独占锁，它同样有包含公平锁和不公平锁两种实现方式，在实例化时将同时实例化 ReadLock 和 WriteLock 实例，本文主要聚焦于 WriteLock 的实现分析，因为 ReentrantReadWriteLock 中的部分实现与 ReentrantLock 一样基于 AbstractQueuedSynchronized 的实现，对于一些相同的逻辑本文不再赘述。

public ReentrantReadWriteLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
    readerLock = new ReadLock(this);
    writerLock = new WriteLock(this);
}

1.1 锁状态码存储

在 ReentrantLock 中，通过 state 参数保存锁状态码，状态码存储着当前锁重入的次数。在 ReentrantReadWriteLock 中同时包含读和写两种锁类型，需要两个状态码来保存锁状态。ReentrantReadWriteLock 将 state 低 16 位用于存储写锁状态，高16位用于存储读锁状态。

static final int SHARED_SHIFT   = 16;
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; }

二、Sync 的公平和非公平实现

**公平锁: ** 多个线程相互竞争时要排队，多个线程按照申请锁的顺序来获取锁。

**非公平锁: ** 多个线程相互竞争时，先尝试插队，插队失败再排队。

Sync 包含 FairSync 和 NonfairSync 两个子类，分别复写了如下两个方法：

  • boolean readerShouldBlock()：如果当前线程在试图获得读锁或操作时时，方法返回 true 表示当前线程需要排队，返回 false 表示线程可以先插队获取锁，或者当前队列为空不需要排队。
  • boolean writerShouldBlock()：如果当前线程在尝试获取写锁或其他操作时，方法返回 true 表示当前线程需要排队，返回 false 表示线程可以在排队前先插队获取锁，或者当前队列为空不需要排队。

2.1 FairSync 公平锁

FairSync 是 ReentrantReadWriteLock 公平锁的实现。FairSync 通过 hasQueuedPredecessors 方法检查当前 AQS 队列，hasQueuedPredecessors 方法在有其他线程的节点排队在队列首部则返回 true ，否则返回 false。所以，在公平锁中获取读、写锁时，只要队列首部是其他线程都需要进行排队，除非队列为空或者队列首部为当期线程，以此保证锁竞争公平。

final boolean writerShouldBlock() {
    return hasQueuedPredecessors();
}
final boolean readerShouldBlock() {
    return hasQueuedPredecessors();
}

2.2 NonfairSync 非公平锁

NonfairSync 是 ReentrantLock 非公平锁的实现。在获取独占锁相关操作时，恒定返回 false ，无论在哪种情况下都将尝试插队；在获取共享锁相关操作时，如果队列不为空，且队列首部节点在等待独占锁，则将返回 true 不进行插队，此操作是为了防止独占锁饥饿。

// 独占锁无论如何都尝试插队
final boolean writerShouldBlock() {
    return false;
}
// 如果队列不为空，且队列首部节点在等待独占锁，则返回true进行排队（避免独占锁饥饿）
final boolean readerShouldBlock() {
    /* As a heuristic to avoid indefinite writer starvation,
     * block if the thread that momentarily appears to be head
     * of queue, if one exists, is a waiting writer.  This is
     * only a probabilistic effect since a new reader will not
     * block if there is a waiting writer behind other enabled
     * readers that have not yet drained from the queue.
     */
    return apparentlyFirstQueuedIsExclusive();
}

问：独占锁是如何产生锁饥饿的？

独占锁饥饿原因在于独占锁仅能被一个线程获取，共享锁可以被多个线程获取。

如果共享锁允许无限插队，假如当前有10个共享锁，执行了一段时间释放了5个共享锁，但是又有5个共享锁插队进来了，如此循环往复，一直有线程持有着共享锁，导致共享锁一直没有被释放，此时独占锁就无法被持有。

apparentlyFirstQueuedIsExclusive 在队列不为空，且 head 后续节点不是共享锁状态时返回 true。

final boolean apparentlyFirstQueuedIsExclusive() {
    Node h, s;
    return (h = head) != null &&
        (s = h.next)  != null &&
        !s.isShared()         &&
        s.thread != null;
}

三、WriteLock 实现

3.1 lock 实现流程

lock 用于获取锁，不响应中断。WriteLock 获取锁的流程整体上和 ReentrantLock 获取锁的流程相同，不同点体现在 tryAcquire 方法。

lock 获取锁时，首先执行的是 tryAcquire 方法， tryAcquire 将直接尝试获取锁，此时不通过 AQS 队列获取锁，线程在 AQS 队列中并不存在对应的 node 节点。如果未获取到锁，此时将进入 AQS 队列排队，addWaiter 步骤中可同时进行队列初始化，队列排队的核心逻辑在 acquireQueued 方法，在该方法中将循环判断当前线程是否时候 AQS 队列的第二个 node 线程（第一个 node 为持有锁线程），如果是的话执行 tryAcquire 进获取锁尝试，如果获取锁失败，将进入 shouldParkAfterFailedAcquire 修改前一个节点的 node 节点状态，然后再次进入循环根据前一个节点状态阻塞当前节点线程，直到被唤醒。

3.1.1 tryAcquire 方法实现

tryAcquire 用于以独占的方式获取锁，返回 boolean 表示获取锁是否成功。tryAcquire 中先获取了当前锁的状态，如果当前锁已被持有，将判断当前持有的锁是不是独占锁、当前线程是否是持有锁的线程和锁状态是否超过最大值，都满足则进行重入；如果当前锁未被持有，则通过 writerShouldBlock 判断是否跳过排队直接尝试获取锁，如果 writerShouldBlock 返回 true 则进行 CAS 获取锁尝试。

protected final boolean tryAcquire(int acquires) {
    /*
     * Walkthrough:
     * 1. If read count nonzero or write count nonzero
     *    and owner is a different thread, fail.
     * 2. If count would saturate, fail. (This can only
     *    happen if count is already nonzero.)
     * 3. Otherwise, this thread is eligible for lock if
     *    it is either a reentrant acquire or
     *    queue policy allows it. If so, update state
     *    and set owner.
     */
    Thread current = Thread.currentThread();
    int c = getState();
    // 取得当前独占锁状态码
    int w = exclusiveCount(c);
    // 当前已经持有了独占锁或者共享锁
    if (c != 0) {
        // 当前未持有独占锁，或者持有锁的不是当前线程，则获取锁失败
        if (w == 0 || current != getExclusiveOwnerThread())
            return false;
        // 独占锁值超过了最大值
        if (w + exclusiveCount(acquires) > MAX_COUNT)
            throw new Error("Maximum lock count exceeded");
        // 修改锁状态
        setState(c + acquires);
        return true;
    }
    // writerShouldBlock 判断是否非公平，是否需要插队
    if (writerShouldBlock() ||
        // CAS 修改锁状态
        !compareAndSetState(c, c + acquires))
        return false;
    // CAS获取锁成功，修改持有锁的线程
    setExclusiveOwnerThread(current);
    return true;
}

3.2 lockInterruptibly 实现流程

lockInterruptibly 用于获取锁，如果收到中断信号则中止获取。除了 tryAcquire 所有实现流程和 ReentrantLock 的 lockInterruptibly 实现流程相同。整体的实现和 lock 方法也是大同小异，只是在 lockInterruptibly 中 AQS 队列接收到中断信号直接终止获取锁，并抛出 InterruptedException 异常，而 lock 仅仅保留了中断标志。

3.3 tryLock 实现流程

不携带时间参数的 tryLock 方法用于尝试获取锁，非公平，不阻塞线程。方法中通过 tryWriteLock 方法来尝试获取锁，整体上获取锁流程和 tryAcquire 方法相同，不同的是去除了判断是否通过 CAS 插队获取锁的判断，无论如何都进行获取锁尝试，所以这是一个非公平的获取锁尝试。

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修改锁状态
    if (!compareAndSetState(c, c + 1))
        return false;
    // 修改成功，修改持有锁线程
    setExclusiveOwnerThread(current);
    return true;
}

携带时间参数的 tryLock 用于在给定的等待时间内尝试获取锁，获取成功则立即返回 true。超过等待时间获取失败或者接收到中断信号则返回 false 。整体执行流程和 ReentrantLock 相同，只是 tryAcquire 方法的逻辑有些不同。

带时间参数的 tryLock 将时间转为纳秒级时间单位，然后传给 tryAcquireNanos。tryAcquireNanos 方法中先直接调用 tryAcquire 尝试获取锁，获取锁失败再调用 doAcquireNanos 方法进行排队。doAcquireNanos 将创建 node 节点加入同步队列，然后以独占定时模式获取锁，尝试获取锁失败后将阻塞指定时间的获取锁线程。当阻塞时间到之后再次尝试获取锁，阻塞时间完成或者在阻塞时接收到中断信号时停止获取锁尝试，最终方法返回值将指定是否成功获取到锁。

3.4 unlock 实现流程

unlock 通过 tryRelease 方法进行锁状态修改和释放锁，如果完全释放了锁，将进行 AQS 队列判断。如果队列已经初始化，将更新当前节点的节点状态为 0，并尝试唤醒 head 后继的第一个等待获取锁的节点。

public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}
3.4.1 tryRelease 方法实现

tryRelease 用于进行释放锁操作，返回值表示是否完全释放了锁。方法首先判断当前线程是否是持有锁线程，如果未持有锁将抛出 IllegalMonitorStateException 异常，然后计算锁状态，如果修改后的锁状态值为 0，表示锁被完全释放，此时将清除持有锁的线程。

protected final boolean tryRelease(int releases) {
    // 当前线程是否持有锁
    if (!isHeldExclusively())
        throw new IllegalMonitorStateException();
    // 计算锁状态
    int nextc = getState() - releases;
    // 锁状态为0表示锁被完全释放，不为0表示只是减扣除重入，线程依旧持有锁
    boolean free = exclusiveCount(nextc) == 0;
    if (free)
        // 清除持有锁线程
        setExclusiveOwnerThread(null);
    // 修改锁状态
    setState(nextc);
    return free;
}

3.5 newCondition 实现流程

WriteLock 和 ReentrantLock 都是实例化的 ConditionObject 类，除了部分方法有差别，整体工作流程和原理相同，本文不做赘述。

四、ReadLock 实现

ReadLock 一些全局变量的介绍：

  • firstReader ：第一个持有共享锁的线程，释放锁后为 null；
  • firstReaderHoldCount ：第一个持有共享锁的线程的持有锁计数，即锁状态；
  • readHolds ：当前线程持有的 ReadLock 锁的数量， 仅在构造函数和 readObject 中初始化，每当线程的共享锁状态下降到 0 时删除；
  • cachedHoldCounter ：最后一个成功获取共享锁线程的缓存；

HoldCounter 对象用于记录持有共享锁的线程，记录了持有锁的线程的线程id和锁计数。

4.1 lock 实现流程

共享锁通过 acquireShared 方法获取锁。获取锁时，先进行获取锁尝试，获取锁失败进入 AQS 队列排队。在获取锁的流程中，创建节点和加入 AQS 进行排队的流程和 WriteLock 相同，区别体现在 tryAcquireShared 获取锁的方法中。

获取锁时，如果其他线程持有了独占锁则直接获取失败，否则将调用 readerShouldBlock 方法判断是否尝试插队获取锁。获取锁时通过 CAS 模式更新 state 写状态的值，更新成功则表示获取锁成功。除此之外还需更新当前线程对应的 ReadLock 锁状态，即锁计数，该值通过 HoldCounter 存储，并通过 cachedHoldCounter 缓存最后一个获取共享锁线程的 HoldCounter。首个持有共享锁的线程较为特殊，通过 firstReader 和 firstReaderHoldCount 存储持有锁的线程和锁状态计数。

4.1.1 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);
    // readerShouldBlock:判断是否需要插队获取锁，公平和非公平锁实现不同
    if (!readerShouldBlock() &&
        // 锁状态小于最大值
        r < MAX_COUNT &&
        // CAS修改锁状态
        compareAndSetState(c, c + SHARED_UNIT)) {
        if (r == 0) {
            // 当前线程为第一个持有共享锁的线程
            firstReader = current;
            firstReaderHoldCount = 1;
        } else if (firstReader == current) {
            // 当前线程为第一个持有共享锁的线程，直接增加共享锁状态
            firstReaderHoldCount++;
        } else {
            // 取得最后一次获取readLock锁线程的缓存
            HoldCounter rh = cachedHoldCounter;
            if (rh == null || rh.tid != getThreadId(current))
                // 缓存的不是当前线程，更新缓存，HoldCounter如果不存在将创建 
                cachedHoldCounter = rh = readHolds.get();
            else if (rh.count == 0)
                // 缓存的readLock锁已被释放，重新添加
                readHolds.set(rh);
            // 增加锁计数
            rh.count++;
        }
        return 1;
    }
    return fullTryAcquireShared(current);
}
4.1.2 fullTryAcquireShared 方法实现

完整版本的获取共享锁流程，处理 CAS 未命中和未在 tryAcquireShared 中处理的可重入读取。这段代码与 tryacquirered 中的代码在一定程度上是冗余的。

在当前方法中进行循环获取锁，获取锁时将会有以下三种情况不同的情况：

  1. 有线程已经持有了独占锁，如果持有独占锁的线程不是当前线程，直接返回 -1 获取锁失败，持有独占锁的线程是当前线程则正常进行共享锁获取。
  2. 未被获取独占锁，但是 readerShouldBlock 为 true，不允许插队获取锁。如果当前线程为第一个持有共享锁的线程，则正常进入获取锁流程。如果非第一次持有锁线程，则需要先判断当前线程是否已经持有了共享锁，未持有共享锁时将清除 readHolds 中的引用，并直接返回 -1 后续通过排队进行锁获取。
  3. 未被获取独占锁，但是 readerShouldBlock 为 false，允许插队获取锁。此时将直接进入获取锁流程。

获取独占锁时通过 CAS 直接尝试修改 state 的值，如果修改成功更新当前持有共享锁线程的状态和缓存，修改失败则进入下一次循环。

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) {
                    rh = cachedHoldCounter;
                    // 取得当前线程的 HoldCounter，先从缓存获取，再从readHolds获取
                    if (rh == null || rh.tid != getThreadId(current)) {
                        rh = readHolds.get();
                        // 锁状态为0删除readHolds的锁引用
                        if (rh.count == 0)
                            readHolds.remove();
                    }
                }
                // 锁状态为0则返回获取锁失败
                if (rh.count == 0)
                    return -1;
            }
        }
        // 共享锁计数为最大值
        if (sharedCount(c) == MAX_COUNT)
            throw new Error("Maximum lock count exceeded");
        // CAS 修改锁状态
        if (compareAndSetState(c, c + SHARED_UNIT)) {
            // 修改前共享锁状态为0，当前为第一个持有锁的线程
            if (sharedCount(c) == 0) {
                firstReader = current;
                firstReaderHoldCount = 1;
            } else if (firstReader == current) {
                // 当前为持有锁线程，当前共享锁的状态加1
                firstReaderHoldCount++;
            } else {
                if (rh == null)
                    rh = cachedHoldCounter;
                // 当前缓存的最后一个获取共享锁的线程不是当前线程，更新缓存
                if (rh == null || rh.tid != getThreadId(current))
                    // HoldCounter如果不存在将创建
                    rh = readHolds.get();
                // 获取到的缓存中锁状态为0，需要重新添加到readHolds
                else if (rh.count == 0)
                    readHolds.set(rh);
                // 增加锁计数
                rh.count++;
                cachedHoldCounter = rh;
            }
            return 1;
        }
    }
}

问：为什么需要循环进行锁获取？

与独占锁不同，共享锁允许多个线程同时持有。独占锁通过 CAS 修改锁状态失败，则表示其他线程修改了锁状态，锁已被其他线程获取，需要进入排队。但是共享锁通过 CAS 修改锁状态失败，并不一定导致当前线程不能获取共享锁，除非其他线程获取了独占锁，所以获取锁失败需要通过循环再次尝试获取，确定锁的状态。

问：ReentrantReadWriteLock如何进行锁降级？

从上述源码分析，如果当前线程持有 WriteLock，是有权再获取ReadLock锁的，所以可以进行锁降级。

降级流程为：获取WriteLock->获取ReadLock->释放->WriteLock

4.1.3 doAcquireShared 方法实现

为当前线程创建 node 节点并加入同步队列尾部进行排队。排队获取锁逻辑与获取独占锁的 acquireQueued 方法相同 。

private void doAcquireShared(int arg) {
    // 创建共享节点，并插入队列尾部
    final Node node = addWaiter(Node.SHARED);
    boolean failed = true;
    try {
        // 当前线程是否被中断
        boolean interrupted = false;
        for (;;) {
            // 取得前一个节点
            final Node p = node.predecessor();
            // 前一个节点为head，表示当前节点可以尝试获取锁
            if (p == head) {
                // 尝试获取锁
                int r = tryAcquireShared(arg);
                if (r >= 0) {
                    // 获取锁成功，更新head节点和引用
                    setHeadAndPropagate(node, r);
                    p.next = null; // help GC
                    // 设置中断状态
                    if (interrupted)
                        selfInterrupt();
                    failed = false;
                    return;
                }
            }
            // shouldParkAfterFailedAcquire：检查和更新未能获取锁的节点的状态。 如果线程应该阻塞，则返回 true。
            // parkAndCheckInterrupt：挂起线程，被唤醒后检查线程是否中断
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                // 保存中断状态
                interrupted = true;
        }
    } finally {
        if (failed)
            // 取消获取锁尝试
            cancelAcquire(node);
    }
}

4.2 lockInterruptibly 实现流程

lockInterruptibly 通过 acquireSharedInterruptibly 方法获取共享锁，整体流程和 ReentrantLock 的 lockInterruptibly 方法相同。

doAcquireSharedInterruptibly 方法为当前线程创建 node 节点并加入同步队列尾部进行排队，该方法响应中断。排队获取锁逻辑与获取独占锁的 doAcquireInterruptibly 方法相同 。

private void doAcquireSharedInterruptibly(int arg)
    throws InterruptedException {
    // 创建共享节点，并插入队列尾部
    final Node node = addWaiter(Node.SHARED);
    boolean failed = true;
    try {
        for (;;) {
            // 取得前一个节点
            final Node p = node.predecessor();
            // 前一个节点为head，表示当前节点可以尝试获取锁
            if (p == head) {
                // 尝试获取锁
                int r = tryAcquireShared(arg);
                if (r >= 0) {
                    // 获取锁成功，更新head节点和引用
                    setHeadAndPropagate(node, r);
                    p.next = null; // help GC
                    failed = false;
                    return;
                }
            }
            // shouldParkAfterFailedAcquire：检查和更新未能获取锁的节点的状态。 如果线程应该阻塞，则返回 true。
            // parkAndCheckInterrupt：挂起线程，被唤醒后检查线程是否中断
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                // 中断时抛出异常
                throw new InterruptedException();
        }
    } finally {
        if (failed)
            // 取消获取锁尝试
            cancelAcquire(node);
    }
}

4.3 tryLock 实现流程

不携带时间参数的 tryLock 方法用于尝试获取锁，非公平，不阻塞线程。与 fullTryAcquireShared 方法相同，为了避免由于并发修改时 CAS 失败，需要循环进行锁获取，除非可以确定无法获取锁（当前已经获取了独占锁，且持有锁线程不是当前线程）。

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");
        // 尝试获取共享锁
        if (compareAndSetState(c, c + SHARED_UNIT)) {
            // 获取共享锁成功
            if (r == 0) {
            	//当前线程为第一个持有共享锁的线程
                firstReader = current;
                firstReaderHoldCount = 1;
            } else if (firstReader == current) {
                // 当前线程为第一个持有共享锁的线程，直接增加共享锁状态
                firstReaderHoldCount++;
            } else {
                // 从缓存中获取当前线程的HoldCounter
                HoldCounter rh = cachedHoldCounter;
                if (rh == null || rh.tid != getThreadId(current))
                    // 未获取到，从readHolds取值或者创建
                    cachedHoldCounter = rh = readHolds.get();
                else if (rh.count == 0)
                    // 状态为0，表示已被从readHolds删除，重新加入
                    readHolds.set(rh);
                rh.count++;
            }
            return true;
        }
    }
}

带时间参数的 tryLock 将时间转为纳秒级时间单位，然后传给 tryAcquireSharedNanos，整体获取锁流程和获取独占锁的流程相同。tryAcquireSharedNanos 方法中先直接调用 tryAcquireShared 尝试获取锁，获取锁失败再调用 doAcquireSharedNanos 方法进行排队。doAcquireSharedNanos 将创建 node 节点加入同步队列，然后以独占定时模式获取锁，尝试获取锁失败后将阻塞指定时间的获取锁线程。当阻塞时间到之后再次尝试获取锁，阻塞时间完成或者在阻塞时接收到中断信号时停止获取锁尝试，最终方法返回值将指定是否成功获取到锁。

4.4 unlock 实现流程

unlock 通过 releaseShared 方法进行释放锁。先调用 tryReleaseShared 方法进行锁状态修改，如果所有共享锁和独占锁都被完全释放，再调用 doReleaseShared 修改 head 节点状态并唤醒后续节点。

4.4.1 tryReleaseShared 方法实现

进行共享锁状态和当前共享锁计数修改，如果共享锁状态为0，表示所有共享锁都被完全释放。

protected final boolean tryReleaseShared(int unused) {
    Thread current = Thread.currentThread();
    // 第一个持有锁的线程为当前线程，删除锁引用
    if (firstReader == current) {
        // assert firstReaderHoldCount > 0;
        if (firstReaderHoldCount == 1)
            firstReader = null;
        else
            firstReaderHoldCount--;
    } else {
        // 取得当前线程对应的HoldCounter
        HoldCounter rh = cachedHoldCounter;
        if (rh == null || rh.tid != getThreadId(current))
            rh = readHolds.get();
        int count = rh.count;
        if (count <= 1) {
        	//当前锁已被完全释放删除HoldCounter
            readHolds.remove();
            if (count <= 0)
                throw unmatchedUnlockException();
        }
        // 锁状态-1
        --rh.count;
    }
    // 可能存在多个共享锁同时unlock，将造成CAS失败，需要重试
    for (;;) {
        int c = getState();
        int nextc = c - SHARED_UNIT;
        // CAS修改status
        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.
            return nextc == 0;
    }
}
4.4.2 doReleaseShared 方法实现

当所有共享锁都被完全释放时执行，修改 head 节点状态，如果 head 状态为 SIGNAL 将唤醒下一个 node 进行获取锁尝试。

private void doReleaseShared() {
    for (;;) {
        Node h = head;
        if (h != null && h != tail) {
            int ws = h.waitStatus;
            if (ws == Node.SIGNAL) {
                //修改head的状态
                if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                    continue;            // loop to recheck cases
            	// head为SIGNAL状态，需要唤醒后续线程
                unparkSuccessor(h);
            }
            // 修改head的状态为PROPAGATE
            else if (ws == 0 &&
                     !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                continue;                // loop on failed CAS
        }
        // 如果head节点改变则需要从新进行状态修改
        if (h == head)                   // loop if head changed
            break;
    }
}

即使有其他线程正在进行获取/释放锁，也要确保 unlock 状态得到传播，这是源码注释的内容，暂时未理解为什么要这么做。

表现上就是当 head 节点状态为 0 时设置状态为 PROPAGATE 和判断 h == head 这两个步骤，如果 head 被修改表示有其他线程通过 AQS 队列获取锁，此时按理不再需要进行锁状态修改了。

4.5 newCondition 实现流程

ReadLock 不包含 Condition 功能，共享锁允许多个线程同时获取，没有线程等待和礼让的需求。调用当前方法将抛出 UnsupportedOperationException 异常。

玖涯菜菜子
关注
专栏目录
ReentrantReadWriteLock之深入源码解析
weixin_53067547的博客
02-01 1516
ReentrantLock是排他锁，在高并发读多写少的场景下，同时还要保证线程安全，如果使用ReentrantLock的效率不是那么好，所以才有了ReentrantReadWriteLock。在讲源码之前，我们对读写锁要有个认知。读读操作是共享的。读写操作是互斥的。写写操作是互斥的。写读操作是互斥的。（写读两个不同线程）单线程获取写锁后，再次获取读锁，可以拿到。（写读操作可以重入）单线程获取读锁后，再次获取写锁，不可以拿到。
ReentrantReadWriteLock源码解析
qq_31602961的博客
06-25 299
ReentrantReadWriteLock源码解析
Java并发-ReentrantReadWriteLock源码分析
yuhongye110的专栏
09-04 400
ReentrantLock实现了标准的互斥重入锁，任一时刻只有一个线程能获得锁。考虑这样一个场景：大部分时间都是读操作，写操作很少发生；我们知道，读操作是不会修改共享数据的，如果实现互斥锁，那么即使都是读操作，也只有一个线程能获得锁，其他的读都得阻塞。这样显然不利于提供系统的并发量。在JDK1.5中，Doug Lea又给我们带来了读写锁ReentrantReadWriteLock，在读-写锁的实现...
Java 读写锁 ReentrantReadWriteLock 源码分析，还没搞懂JVM
m0_63174420的博客
11-13 301
Sync() { // 初始化 readHolds 这个 ThreadLocal 属性 readHolds = new ThreadLocalHoldCounter(); // 为了保证 readHolds 的内存可见性 setState(getState()); // ensures visibility of readHolds } … } state 的高 16 位代表读锁的获取次数，包括重入次数，获取到读锁一次加 1，释放掉读锁一次减 1 state 的低 16 位代表写锁的获取次数，因为写
Java并发Concurrent包的锁（四）——读写锁源码分析
在梅边的专栏
03-06 436
本文对读写锁源码进行了比较详细的分析。 另外可以参考可重入锁 ReentrantLock 的分析：Java并发Concurrent包的锁（三）——ReentrantLock源码分析 ReadWriteLock接口ReadWriteLock 维护了一对相关的锁，一个用于只读操作，另一个用于写入操作。只要没有 writer，读取锁可以由多个 reader 线程同时保持。写入锁是独占的。public
Java并发编程进阶——并发锁
行者无疆的博客
03-14 4285
1 JAVA 多线程锁介绍 1.1 悲观锁 定义：悲观锁指对数据被外界修改持保守态度，认为数据很容易就会被其他线程修改（很悲观），所以在数据被处理前先对数据进行加锁，并在整个数据处理过程中，使数据处于锁定状态。 悲观锁的实现：开发中常见的悲观锁实现往往依靠数据库提供的锁机制，即在数据库中，在对数据记录操作前给记录加排它锁。如果获取锁失败，则说明数据正在被其他线程修改，当前线程则等待或者抛出异常。如果获取锁成功，则对记录进行操作，然后提交事务后释放排它锁。 实例：Java 中的 synchronized 关键
JAVA并发编程——源码原理全面剖析与重点梳理
lianghongliang66的博客
05-25 1227
帧与帧栈 每个线程有一块栈内存 每个栈由多个栈帧组成，每个栈帧对应每次方法调用占用的内存 每个线程只能有一个活动栈帧，对应当前正在执行的那个方法 线程上下文切换 线程的CPU时间片用完 垃圾回收 有更高优先级的线程需要运行 线程自己调用了sleep、yield、wait、join、park、synchronized、lock等方法 其中程序计数器的作用 操作系统保存当前线程的状态，记住下一条jvm指令的执行地址，用于恢复线程的状态 PS：状态：程序计数器、栈中每个帧栈的信息 线程状态
Java并发系列（7）——AQS与显式锁实现原理
JinchaoLv的博客
07-24 376
接上一篇《Java并发系列（6）——AQS与显式锁的使用》 文章目录5.4 AQS 实现原理5.4.1 原理图5.4.1.1 数据结构5.4.1.2 AQS 如何管理线程5.4.1.3 AQS 是公平锁还是非公平锁5.4.2 核心源码5.4.2.1 acquire 方法5.4.2.2 release 方法5.4.2.3 acquireShared 方法5.4.2.4 releaseShared 方法5.4.2.5 await 方法5.4.2.6 signal 方法5.4.2.7 s
死磕 java同步系列之CyclicBarrier源码解析——有图有真相
彤哥读源码
06-28 240
问题 （1）CyclicBarrier是什么？ （2）CyclicBarrier具有什么特性？ （3）CyclicBarrier与CountDownLatch的对比？ 简介 CyclicBarrier，回环栅栏，它会阻塞一组线程直到这些线程同时达到某个条件才继续执行。它与CountDownLatch很类似，但又不同，CountDownLatch需要调用countDown()方法触发事件，而Cycl...
ReentrantReadWriteLock源码分析
CBeann的博客
05-10 344
构造方法分析 //无参构造方法调用有参构造方法，并且传入一个参数为false public ReentrantReadWriteLock() { this(false);//----->跟进去 } //fair为false,表示创建一个非公平的AQS public ReentrantReadWriteLock(boolean fair) { sync = fair ? new FairSync() : new NonfairSync();
ReentrantReadWriteLock 源码分析
weixin_45359574的博客
06-27 229
目录概述属性分析读锁的获取读锁的释放写锁的获取写锁的释放总结 概述 ReentrantReadWriteLock 也称作读写锁。读锁是共享的，多个线程可以同时获取到读锁；写锁是排他的，当一个线程获取到写锁，其它线程只能等待写锁被释放才能获取。且支持锁的降级，不支持锁的升级，也就是说一个线程获取到了写锁，则它还可以获取该线程的读锁；而一个线程获取到了读锁，不能再获取写锁。因为读锁是允许多个线程读的，如果多个持有读锁的线程都想要升级写锁，造成了互相等待，就会形成死锁，但是写锁降级成读锁确实可以的，因为获取写锁的
ReentrantReadWriteLock读写锁源码解析
qq_34656982的博客
01-24 316
1.读写锁是基于AQS的构建，它包含有读锁和写锁，含有公平和非公平机制。Sync继承AbstractQueuedSynchronizer，它是构建锁的核心。 业务场景就是对一个共享资源的读频率大于写， public class ReentrantReadWriteLock implements ReadWriteLock, java.io.Serializable { private static final long serialVersionUID = -699
读写锁 ReentrantReadWriteLock源码分析
m0_73311735的博客
10-30 530
在 ReentrantLock 中，使用 Sync ( 实际是 AQS )的 int 类型的 state 来表示同步状态，表示锁被一个线程重复获取的次数。但是，分割之后，读写锁是如何迅速确定读锁和写锁的状态呢？通过位运算。根据状态的划分能得出一个推论：S不等于0时，当写状态（S&0x0000FFFF）等于0时，则读状态（S>>>16）大于0，即读锁已被获取。代码实现：java.util.concurrent.locks.ReentrantReadWriteLock.Sync。
ReentrantReadWriteLock读写锁源码解读
李哈zzz的博客
02-27 476
目录 前言 正文 ReentrantLock和ReentrantReadWriteLock的区别 ReentrantReadWriteLock的源码解读 ReentrantReadWriteLock内部结构解读 读锁上锁的实现解读 读锁释放锁的实现解读 写锁上锁实现解读 写锁释放实现解读 源码结论总结(方便面试) 总结 课程推荐 前言 目前也是金三银四跳槽找工作的好时机。小伙伴们可能在面试的时候被面试官问到很多关于多线程方面一系列的连锁问题。比如你有了解Java的多线程吗
Java并发编程：读写锁ReentrantReadWriteLock与StampLock解析
"这篇资料主要介绍了Java并发编程中的读写锁ReentrantReadWriteLock以及相关的StampLock，强调了在读多写少的并发场景下，读写锁的优势。内容包括读写锁的基本概念、特性、使用方法，以及ReentrantReadWriteLock的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

玖涯菜菜子

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值