全网最详细的AbstractQueuedSynchronizer(AQS)源码剖析（一）AQS基础

AbstractQueuedSynchronizer(AQS)源码解析（一）——AQS基础

<code>AbstractQueuedSynchronizer</code>（以下简称AQS）的内容确实有点多，博主考虑再三，还是决定把它拆成三期。原因有三，一是放入同一篇博客势必影响阅读体验，而是为了表达对这个伟大基础并发组件的崇敬之情。第三点其实是为了偷懒。 又扯这么多没用的，还是直接步入正题吧~

AQS是一个抽象类，它是实现多种并发同步工具的核心组件。比如大名鼎鼎的可重入锁（<code>ReentrantLock</code>），它的底层实现就是借助内部类<code>Sync</code>，而<code>Sync</code>类就是继承了AQS并实现了AQS定义的若干钩子方法。这些并发同步工具包括：

<code>ReentrantLock</code>（ReentrantLock可重入锁—源码详解）

<code>ReentrantReadWriteLock</code>（全网最详细的ReentrantReadWriteLock源码剖析（万字长文））

<code>Semaphore</code>（Semaphore信号量源码解析）

<code>CountDownLatch</code>（CountDownLatch源码阅读）

从设计模式上来看，AQS主要使用的是模板方法模式（Template Method Pattern）。它提供了若干钩子方法供子类实现（如<code>tryAcquire</code>、<code>tryRelease</code>等），AQS的模板方法（如<code>acquire</code>、<code>release</code>等）会调用这些钩子方法。子类使用AQS的方式就是直接调用AQS的模板方法，并重写这些模板方法涉及到的特定钩子方法即可。不需要调用的钩子方法可以不用重写，AQS为它们均提供了默认实现：抛出<code>UnsupportedOperationException</code>异常

此外，AQS也提供了其他一些方法供子类调用，如<code>getState</code>、<code>hasQueuedPredecessors</code>等方法，方便子类获取、判断同步器的状态

什么是钩子方法？ 钩子方法的概念源于模板方法模式，这种模式是在一个方法中定义了算法的骨架，某些关键步骤会交给子类去实现。模板方法在不改变算法本身结构的情况下，允许子类自定义其中一些关键步骤 这些关键步骤可以由父类定义成方法，这些方法可以是抽象方法，或钩子方法 抽象方法：父类定义但不实现，由<code>abstract</code>关键字标识 钩子方法：父类定义且实现，但这种实现一般都是空实现，并没有任何意义，这么做只是为了方便子类根据需要重写特定的钩子方法，而不用实现所有的钩子方法

AQS的核心思想：

使用一个<code>volatile int</code>变量<code>state</code>（也被称为资源），进行同步控制，但是<code>state</code>在不同的同步工具实现中具有不同的语义。另外配合<code>Unsafe</code>类提供的CAS操作，原子性地修改<code>state</code>值，保证其线程安全性

AQS内部维护了一个同步队列，用来管理排队的线程。另外需要借助<code>LockSupport</code>类提供的线程阻塞、唤醒方法

作者：酒冽        出处：https://www.cnblogs.com/frankiedyz/p/15673957.html

版权：本文版权归作者和博客园共有

转载：欢迎转载，但未经作者同意，必须保留此段声明；必须在文章中给出原文连接；否则必究法律责任

AQS使用<code>volatile int</code>变量<code>state</code>来作为核心状态，所有的同步控制都是围绕这个<code>state</code>来进行的，<code>volatile</code>保证其内存可见性，并使用CAS确保<code>state</code>的修改是原子的。<code>volatile</code>和CAS同时存在，就保证了<code>state</code>的线程安全性

对于不同的同步工具实现来说，语义是不同的，如下：

<code>ReentratntLock</code>：表示当前线程获取锁的重入次数，0表示锁空闲

<code>ReentrantReadWriteLock</code>：<code>state</code>的高16位表示读锁数量，低16位表示写锁数量

<code>CountDownLatch</code>：表示当前的计数值

<code>Semaphore</code>：表示当前可用信号量的个数

针对<code>state</code>这个核心状态，AQS提供了<code>getState</code>、<code>setState</code>等多个获取、修改方法，源码如下：

AQS内部维护了一个同步队列（网上有些文章会叫它为CLH队列，至于为啥叫这个我也不知道-_-||，但不重要~）。队列中的每个节点都是<code>Node</code>类型其源码如下：

<code>prev</code>、<code>next</code>用于保存该节点的前驱、后继节点，表明这个同步队列是一个双向队列

<code>Node</code>的<code>thread</code>域保存了对应的线程，只有在创建时赋值，使用完要null掉，以方便GC

<code>Node</code>使用<code>SHARED</code>、<code>EXCLUSIVE</code>两个常量来标记该线程是由于获取共享资源、互斥资源失败，而被阻塞并放入到同步队列中进行等待

<code>Node</code>使用<code>waitStatus</code>来记录当前线程的等待状态，通过CAS进行修改。它的取值可以是：

<code>CANCELLED</code>：表示该节点由于超时或中断而被取消。该状态不会再转变为其他状态，而且该节点的线程再也不会被阻塞

<code>SIGNAL</code>：表示其后继节点（后面相邻的那个节点）需要被唤醒，即该线程被释放或被取消时，必须唤醒其后继节点

<code>CONDITION</code>：表示该节点的线程在条件队列中等待，而非在同步队列中。如果该条件变量<code>signal</code>该节点后，该节点会被转移到同步队列中参与资源竞争

<code>PROPAGATE</code>：只有在共享模式下才会被用到，表示无条件传播状态。引入这个状态是为了解决共享模式下并发释放而引起的线程挂起的bug，这里不多解释，网上有文章给出了更加详细的解释，见下方

AQS：为什么需要PROPAGATE？ AQS源码深入分析之共享模式-你知道为什么AQS中要有PROPAGATE这个状态吗？

AQS中维护了一个同步队列，它通过两个指针标记队头、队尾，分别是<code>head</code>和<code>tail</code>，源码如下：

该队列的出入规则遵循FIFO（First In, First Out）

注意：如果该同步队列非空，那么<code>head</code>其实并不是指向第一个线程对应的<code>Node</code>，而是指向一个空的<code>Node</code>

接下来让我们剖析一下AQS针对这个同步队列设计的入队、出队算法

入队事件主要在线程尝试获取资源失败时触发。当线程尝试获取资源失败之后，会将该线程加入到同步队列的队尾

入队算法的源码见AQS的<code>addWaiter</code>方法，如下：

首先为该线程创建一个<code>Node</code>节点，<code>mode</code>可以是<code>Node.EXCLUSIVE</code>或<code>Node.SHARED</code>，表示两种不同的模式。

之后直接CAS试图将其入队。这里注意，如果队列本身为空，或CAS竞争失败，才会进入<code>enq</code>方法。这里<code>addWaiter</code>方法出于性能考虑，先尝试快捷的入队方式，不成功才执行<code>enq</code>方法

<code>enq</code>方法是完整的入队逻辑，源码如下：

<code>enq</code>中的代码都包含在<code>for</code>循环中，如果CAS失败，就会不断循环CAS直到成功为止

注意，这段代码也体现出同步队列的三个特点：

入队都是从队尾

进入队列的操作都是CAS操作，保证了线程安全性

如果队列为空，则<code>head</code>和<code>tail</code>都为null；如果不为空，<code>head</code>指向的节点并不是第一个线程对应的节点，而是一个哑节点

出队事件主要发生在：位于同步队列中的线程再次获取资源，并成功获得时

出队算法在AQS中并没有直接对应的方法，而是零散分布在某些方法中。因为获取资源失败而被阻塞的线程被唤醒后，会重新尝试获取资源。如果获取成功，则会执行出队逻辑

例如，在<code>acquireQueued</code>方法中，就包含了出队事件：

出队的逻辑体现在第6-9行，此时<code>p</code>指向<code>head</code>指向的空节点，而<code>node</code>是队首元素（不是第一个空节点）

首先调用<code>setHead</code>方法，将<code>head</code>指向<code>node</code>、将<code>node</code>的<code>thread</code>域、<code>prev</code>域置空，然后将<code>head</code>的<code>next</code>域置空，以方便该节点的GC

线程会因为超时或中断而被取消，之后不会再参与锁的竞争，会等待GC

取消的过程见<code>cancelAcquire</code>方法，该方法的调用时机都是在获取资源失败之后，而失败就是由于超时或中断。其源码如下：

总之，<code>cancelAcquire</code>方法就是将目标节点<code>node</code>的<code>thread域置空</code>，并将<code>waitStatus</code>置为<code>CANCELLED</code>

这里有一个问题：<code>node</code>的后继节点<code>next</code>的<code>prev</code>指针仍然指向<code>node</code>，没有更新为<code>pred</code>，这不仅语义上是错误的，而且会阻碍<code>node</code>被GC。那么何时进行更新？ 答：任何其他线程尝试获取锁失败之后，都会被放入同步队列，然后调用<code>shouldParkAfterFailedAcquire</code>方法判断是否应该被阻塞。如果发现当前节点的前驱节点被置为<code>CANCELLED</code>，就会执行：

此外，<code>cancelAcquire</code>方法也会做类似的操作，如下：

这两处都会更新被取消节点的后继节点的<code>prev</code>指针，所以前面说到的的问题根本不存在

注意：<code>cancelAcquire</code>的调用时机一般都是在获取锁逻辑后面的<code>finally</code>块中，如果获取失败就会调用<code>cancelAcquire</code>方法。获取失败的原因主要有两个，中断或超时

总结：

节点被取消的原因：获取锁超时或在获取的过程中被中断

取消节点的主要逻辑：将其<code>waitStatus</code>修改为<code>CANCELLED</code>。再将节点<code>thread</code>域置空，将指向它的<code>next</code>指针指向其后继节点，以方便GC

好了，到这里为止，我们就完成了对AQS基本结构的分析。这里如果有不懂的地方，可以暂时跳过，等看完后续博客再回头看这篇，应该就能明白了 下一篇我们会逐步剖析AQS如何实现对资源的获取和释放，go go go！

全网最详细的AbstractQueuedSynchronizer(AQS)源码剖析（一）AQS基础

全网最详细的AbstractQueuedSynchronizer(AQS)源码剖析（二）资源的获取和释放

全网最详细的AbstractQueuedSynchronizer(AQS)源码剖析（三）条件变量

愿归来仍是少年！

    作者：酒冽

    出处：https://www.cnblogs.com/frankiedyz/p/15673957.html

    版权：本文版权归作者和博客园共有

    转载：欢迎转载，但未经作者同意，必须保留此段声明；必须在文章中给出原文连接；否则必究法律责任