19 KiB
因收到Google相关通知，网站将会择期关闭。相关通知内容
12 AQS：保证并发安全的终极奥秘（下）
我们在前几节课中学习了 ReentrantLock 或者 CountDownLatch 的 AQS 应用原理，本节将继续学习相比前两种稍微复杂一点的 ReentrantReadWriteLock。
它相对复杂的原因有以下几点：
ReentrantReadWriteLock 存在两种锁的形式，独占锁和共享锁，我们需要对独占锁和共享锁分别进行分析。 ReentrantReadWriteLock 在应用 AQS 的时候，相对于前几节课对于 state 的应用上，ReentrantReadWriteLock 使用一个 state 值维护了独占锁和共享锁两种形式。
在本节课中，我们还是以 ReentrantReadWriteLock 中更为好理解的公平锁作为切入点进行深入分析。
一、前期准备
刚刚我们在上面说过，ReentrantReadWriteLock 使用一个 state 维护了两个状态。在学习之前，我们需要先去学习如何使用一个 32 位的 int 值来表示两种状态，主要是对于 Java 位运算的知识点。
我们前几节课了解到，AQS 中 state 主要是为了记录加锁的次数或者计数次数，但是在 ReentrantReadWriteLock 中存在读锁（共享锁）和写锁（独占锁）两种，那么此时只有一个 state 肯定是无法满足的，因为 state 是一个 int 值，我们知道 int 在 Java 占 32 位字节，所以我们考虑将 32 位分为高 16 位和低 16 位，如下图所示：
我们可以使用高 16 位存储共享锁，低 16 位存储独占锁，这 32 位最终表示为 10 进制就是一个数字，比如上图表示的就是 0。
那么我们如何计算来单独获取到共享锁或者独占锁的数值呢？
- 获取独占锁的数量级
在 Java 中存在一种位运算 & 运算，这种运算模式下，它将两个操作数的每个对应位进行与运算，如果两个对应位都是 1，则结果位为 1，否则为 0，运算顺序如下图所示：
上图就是 & 运算的过程，只有全为 1，最终结果才为 1，如果我们使用低 16 位存储独占锁，那么独占锁的最大数量是低 16 位全部为 1 也就是 65535。
我们假设使用一个低 16 位全部都是 1 的二进制与 state 作 & 运算，那么我们是不是就能够得到低 16 位的数值呢？
可能没有了解过位运算的同学会懵，没关系，我们用图来表示：
也就是说，只要通过低 16 位全是 1 的值与 state 进行 & 运算，我们就能得到低 16 位的值，当然因为 16 位数据最大只能表示 65535，所以如果 state 的值大于 65535，那么计算就会出问题。所以，我们需要规定，独占锁的数量必须小于等于 65535！
我们看一下，ReentrantReadWriteLock 计算独占锁的规则，先不要管代码在哪里，后面会统一说明：
static final int SHARED_SHIFT = 16; //得出的结果就是65535 低16位全为1 static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
我们简单说明一下 EXCLUSIVE_MASK 的运算方式，<<这个符号就是左移运算符，目的是将一个数据向左边移动 16 位，空缺位置补 0，然后再进行 -1 操作。
注意，因为这个不是本节课的重点，这里的位运算只是为了让新手更加容易理解，事实上进行 -1 操作的时候，二进制运算中会转换为（xxx + -1）来进行运算，这涉及到了补码的知识点。如果大家想学习，可以在网上查找资料学习，这里不做太多的讲解。
在上述的代码中，c 就是 state，而 EXCLUSIVE_MASK 就是基准值（低 16 位全为 1 的数据），通过 state 与基准值进行位运算，我们就能够得到低 16 位的值，也就是独占锁的数量值。
- 获取共享锁的数量级
我们上文说到 state 采用了低 16 位来存储了独占锁，所以从 0 ~ 65535 的数据位置已经被独占锁全部占用，所以高 16 位存储共享锁就需要从 65536 来计算，也就是在二进制中至少需要第 17 位也就是高 16 位的最后一位存在数据才能存储共享锁的数量级。
如图所示，我们分别表示共享锁的数量为 1、2、3：
从上图可以看到，如果我们想要获取高 16 存储的实际的数值，需要将低 16 位的干扰排除掉，然后计算就能得到十进制的数据，所以我们需要用到另外一个计算符 >>>，这个符号在 Java 中可以将二进制数据无符号右移，缺少的位置补充为 0，如图所示：
我们通过无符号右移 16 位，就能够完全抛弃掉低 16 位对我们运算的影响，从而达到计算共享锁数量级的目的。
如果我们想要对高 16 位进行 +1 操作呢？此时因为我们操作的是高 16 位，所以直接对 state + 1 是不行的，每一次对高 16 位 +1 都需要在实际的十进制中增加 65536 的数值。
依旧是使用一张图来证明演算过程，我们现在对高 16 位进行 +1 操作：
至此，我们学习了，如果想要计算高 16 位的值，需要将数据无符号右移 16 位来得到共享锁的数量级；如果想对当前共享锁的数量级数量 +1 ，则需要对 state + 65536。
我们来看下 ReentrantReadWriteLock 对这个的应用。
获取共享锁的数量级：
static final int SHARED_SHIFT = 16;
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
可以看到，这里计算共享锁数量级方法的过程是计算高 16 位，计算过程与我们上文分析的一致。
对共享锁的数量级 +1 操作：
static final int SHARED_SHIFT = 16; static final int SHARED_UNIT = (1 << SHARED_SHIFT);
compareAndSetState(c, c + SHARED_UNIT)
这里可以看到，对于共享锁的数量级的修改是直接使用 CAS 修改为当前的 state + 65536，计算过程与我们上文说的一致。
二、源代码分析
至此，我们已经学习了在 ReentrantReadWriteLock 中如何通过一个 state 来维护两个锁的数量值，我们来分别分析一下共享锁和独占锁的加解锁的过程。
这里还是以公平锁为例进行分析，非公平锁你在闲暇之余可以根据这几章的所学来分析一下。
- 读锁的加解锁
（1）加锁
直接进入到 java.util.concurrent.locks.ReentrantReadWriteLock.Sync#tryAcquireShared，源码的寻找过程跟前几章的寻找过程一致：
protected final int tryAcquireShared(int unused) { //获取当前的线程 Thread current = Thread.currentThread(); //获取当前的state的值 int c = getState(); //判断是否存在独占锁 if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current) return -1; //获取共享锁 int r = sharedCount(c); //是否需要排队等动作 共享锁的数量是否小于65535 cas修改高16位是否成功 if (!readerShouldBlock() && r < MAX_COUNT && compareAndSetState(c, c + SHARED_UNIT)) { //首次加锁 if (r == 0) { //记录首次的线程 （优化） firstReader = current; //首次线程的加锁数量级 （优化） firstReaderHoldCount = 1; } else if (firstReader == current) { //如果还是首个线程 则直接累加，此时还没有竞争呢 firstReaderHoldCount++; } else { //存在线程竞争 则使用ThreadLocal缓存一个HoldCounter加锁的计数器 HoldCounter rh = cachedHoldCounter; if (rh == null || rh.tid != getThreadId(current)) cachedHoldCounter = rh = readHolds.get(); else if (rh.count == 0) readHolds.set(rh); //计数器累加操作 rh.count++; } return 1; } //当上面共享锁加锁失败，则开始循环迭代加锁 return fullTryAcquireShared(current); }
有了前面的知识其实很好理解这段代码，我们在学习 ReentrantReadWriteLock 的时候学习过它的特性，读写锁存在互斥性，即读锁和写锁不能同时共存，所以首先需要根据位运算来计算低 16 位是否存在写锁，如果存在直接加锁失败，如果不存在则继续。
在确认此时没有写锁后，根据位运算计算高 16 位的读锁的数量，当判断不需要排队和读锁的数量不超过 65535 并且 CAS 修改成功的情况下，开始执行读锁的加锁逻辑，主要有以下几个步骤：
如果读锁数量级为 0，则证明只有一个线程在获取锁，此时不存在锁竞争问题，所以直接通过维护 firstReader、firstReaderHoldCount 这两个变量来记录持有锁的线程和读锁的数量级，而不是使用 ThreadLocal 来记录。这样可以提高效率，因为 ThreadLocal 效率虽然高，但是依旧会损失一部分性能。 当读锁数量级不为 0，则证明此时可能不止一个线程在持有读锁，于是先判断是否是可重入锁的情况，如果是可重入锁，证明此时还不存在锁竞争问题，所以依旧使用 firstReaderHoldCount 来记录加锁次数，以保证重入锁的功能正确性。 当读锁数量级不为 0 且不是重入锁的情况下，证明此时一定存在锁竞争问题，于是开始对每一个线程使用 ThreadLocal 来单独记录一个加锁计数器，从而保证某一个线程重入锁的获取次数的正常计算。
fullTryAcquireShared 方法主要是进行兜底的操作，当发现线程需要排队、加锁次数超过 65535、CAS 加锁失败的时候进行兜底，内部工作机制如下：
当发现线程需要排队的时候直接返回 -1，进行入队操作。 当发现加锁次数超过 65535 时，抛出异常 new Error("Maximum lock count exceeded")。 当 CAS 加锁失败的时候，使用死循环来不断地尝试修改 CAS 直至成功为止（自旋锁）。
我们使用一个流程图来描述整个过程：
总结来说，共享锁的加锁逻辑就是先判断是不是存在写锁，存在写锁就直接加锁失败入队，不存在就加锁成功并修改 state 的高 16 位数据，并在每一个线程维护一个计数器，来计算每一个线程加锁的次数。
（2）解锁
共享锁的解锁比较简单，解锁过程简单来说无非就是将累加器中的累加次数 -1，同时将 state 中的高 16 位 -1（state - 65536），然后再通知等待队列中的任务进行解除阻塞。
源码位置：java.util.concurrent.locks.AbstractQueuedSynchronizer#releaseShared。
public final boolean releaseShared(int arg) { if (tryReleaseShared(arg)) { doReleaseShared(); return true; } return false; }
这里我们还是分两部分进行解析 tryReleaseShared 和 doReleaseShared。
tryReleaseShared
java.util.concurrent.locks.ReentrantReadWriteLock.Sync#tryReleaseShared protected final boolean tryReleaseShared(int unused) { Thread current = Thread.currentThread(); //如果当前解锁线程是首个加锁的线程，证明没有竞争直接修改局部变量即可 if (firstReader == current) { if (firstReaderHoldCount == 1) firstReader = null; else firstReaderHoldCount--; } else { //存在竞争 直接修改ThreadLocal中的累加器 HoldCounter rh = cachedHoldCounter; if (rh == null || rh.tid != getThreadId(current)) rh = readHolds.get(); int count = rh.count; if (count <= 1) { readHolds.remove(); if (count <= 0) throw unmatchedUnlockException(); } --rh.count; } for (;;) { int c = getState(); int nextc = c - SHARED_UNIT; //使用CAS修改数据 CAS修改失败则开始自旋修改，直至修改成功 if (compareAndSetState(c, nextc)) //重入锁的情况下，加锁次数减少一次不会为0 return nextc == 0; } }
正如我们前面分析的，解锁逻辑总共就做了两件事：
修改累加器，如果累加器为 1，则直接删除，证明该线程不再持有共享锁。 使用自旋的方式 CAS 修改 state 的值。
我们在这一步也就基本上了解了，有一部分同学在学习加锁的时候疑惑的 HoldCounter 的意义，它就是为了记录某一个线程的加锁次数，以方便在后续解锁的时候，释放重入锁进行计数。HoldCounter 与 state 不同的是，HoldCounter 记录的是单个线程持有读锁的次数，而 state 记录的是整个锁的状态，包括共享锁的持有次数和排他锁的持有信息。
doReleaseShared
在上一步释放锁成功后，会尝试将等待队列中的任务进行唤醒，具体方法如下：
java.util.concurrent.locks.AbstractQueuedSynchronizer#doReleaseShared private void doReleaseShared() { for (;;) { //获取头节点 Node h = head; if (h != null && h != tail) { int ws = h.waitStatus; if (ws == Node.SIGNAL) { //初始化状态waitStatus为0 if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0)) continue; // 将head节点的下一个节点解除阻塞 unparkSuccessor(h); } else if (ws == 0 && !compareAndSetWaitStatus(h, 0, Node.PROPAGATE)) continue; } if (h == head) break; } }
这一块代码主要的作用就是将 head 节点后面的节点调用 unPark 方法进行解除阻塞，以达到让等待队列中的任务能够继续执行的目的。
这里我们将共享锁（读锁）的加解锁做了一个详细的介绍，事实上，它的加解锁方式与 ReadWriteLock 的根本区别就是对于共享锁的加锁，在没有写锁的情况下，会直接加锁成功，同时在 state 中维护读锁的加锁数据。存在写锁，则直接加锁失败入队。
- 写锁的加解锁
我们在上文详细学习了读锁的加解锁操作，下面我们开始正式分析写锁的加解锁的操作。
（1）加锁
代码位置在：java.util.concurrent.locks.AbstractQueuedSynchronizer#acquire。
public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }
这里可以看到，它的加锁方式与 ReentrantLock 一样，我们只需要重点关注 tryAcquire 方法在 ReentrantReadWriteLock 中的实现就行了，其他方法在前面分析过，不再重复讲解。
先思考一下，如果是你，你该对写锁如何加锁？
首先，它是一个独占锁，所以我们需要先判断 state 的低 16 位是不是已经存在独占锁了，如果已经存在独占锁了，那么我们就需要判断是不是重入锁！如果 state 中已经存在独占锁了，而且也不是重入锁，那么直接加锁失败，将任务放到任务队列中就可以了。
其次，如果没有独占锁，因为 16 位字节的限制，所以独占锁的限制不能超过 65535 个，如果超过了就直接报错。
然后在既没有独占锁占用又没有超过最大值的情况下，我们直接就 state + 1，然后返回加锁成功就可以了。
那么，我们一起来看一下源码中是如何做的。
源码位置：java.util.concurrent.locks.ReentrantReadWriteLock.Sync#tryAcquire。
protected final boolean tryAcquire(int acquires) { //获取当前的线程 Thread current = Thread.currentThread(); //获取当前State的值 int c = getState(); //计算低16位的值 int w = exclusiveCount(c); //如果 state!=0 证明state存在读锁或者写锁 if (c != 0) { //如果w = 0 证明State中存在读锁 不存在写锁，读写不能共存，所以直接加锁失败 //如果w != 0 这个名State中存在写锁，此时需要判断是不是重入锁，不是重入锁也直接失败 if (w == 0 || current != getExclusiveOwnerThread()) return false; //如果没有读锁，那么判断写锁数量是否超过最大值，超过直接报错 if (w + exclusiveCount(acquires) > MAX_COUNT) throw new Error("Maximum lock count exceeded"); //经过上面的判断，这里就符合w!=0 而且符合重入锁的规则，直接向上累加加锁次数就可以了 setState(c + acquires); return true; } //如果state == 0 证明即不存在写锁也不存在读锁，此时需要判断等待队列中是否存在任务，不存在而且CAS能够修改成功就返回加锁成功，否则加锁失败 if (writerShouldBlock() || !compareAndSetState(c, c + acquires)) return false; setExclusiveOwnerThread(current); return true; }
从代码注释中可以看到，代码中的设计原理与我们之前设想的基本一致。还是老规矩，我们使用一张流程图来说明问题：
（2）解锁
了解了写锁的加锁步骤之后，解锁步骤能猜出来：
将 state - 1； 判断当前 state 的写锁数量，如果为 0 的话证明重入锁释放完毕，直接将加锁线程置空，并解锁成功。
猜测完毕后，我们来看实际的源码。
源码位置：java.util.concurrent.locks.AbstractQueuedSynchronizer#release。
public final boolean release(int arg) { if (tryRelease(arg)) { Node h = head; if (h != null && h.waitStatus != 0) unparkSuccessor(h); return true; } return false; }
同样的，代码我们都分析过，我们这里只重点分析 tryRelease。
源码位置：java.util.concurrent.locks.AbstractQueuedSynchronizer#tryRelease。
protected final boolean tryRelease(int releases) { //判断解锁线程是不是加锁线程 不是就直接报错 if (!isHeldExclusively()) throw new IllegalMonitorStateException(); //state - 1 int nextc = getState() - releases; //判断重入锁是否解锁成功 boolean free = exclusiveCount(nextc) == 0; if (free) //加锁线程置空 setExclusiveOwnerThread(null); //cas设置state setState(nextc); return free; }
可以看到，与我们的猜测基本一致，比较简单，这里不再画图说明。
三、总结
本节课我们从源码角度学习了 ReentrantReadWriteLock 的写锁和读锁的加解锁原理，也从源码角度上说明了 ReentrantReadWriteLock 是如何通过 AQS 中一个 state 来控制两个锁的状态的。通过这一节课的学习，我们也了解到了读写锁互斥、写锁互斥的原理，相当于对我们前面的所学做了一个验证！
大家闲下来的时候，也可以自己分析一下非公平锁的源码，看看你是否已经搞明白 ReentrantReadWriteLock 对于 AQS 的使用！