前言

如果你想深入研究Java并发的话，那么AQS肯定是绕不开的一块知识点，Java并发包很多的同步工具类底层都是基于AQS来实现的，比方咱们工作中常常用的Lock工具ReentrantLock、栅栏CountDownLatch、信号量Semaphore等，而且对于AQS的知识点也是面试中常常考查的内容，所以，无论是为了更好的应用还是为了应酬面试，深刻学习AQS都很有必要。

CAS

学习AQS之前，咱们有必要理解一个知识点，就是AQS底层中大量应用的CAS，对于CAS，大家应该都不生疏，如果还有哪位同学不分明的话，能够看看我之前的文章《面试必问系列：乐观锁和乐观锁的那些事儿》，这里不多复述，哈哈，给本人旧文章加了浏览量

AQS简介

本文配角正式退场。

AQS，全名AbstractQueuedSynchronizer，是一个抽象类的队列式同步器，它的外部通过保护一个状态volatile int state(共享资源)，一个FIFO线程期待队列来实现同步性能。

state用关键字volatile润饰，代表着该共享资源的状态一更改就能被所有线程可见，而AQS的加锁形式实质上就是多个线程在竞争state，当state为0时代表线程能够竞争锁，不为0时代表以后对象锁曾经被占有，其余线程来加锁时则会失败，加锁失败的线程会被放入一个FIFO的期待队列中，这些线程会被UNSAFE.park()操作挂起，期待其余获取锁的线程开释锁才可能被唤醒。

而这个期待队列其实就相当于一个CLH队列，用一张原理图来示意大抵如下：

根底定义

AQS反对两种资源分享的形式：Exclusive（独占，只有一个线程能执行，如ReentrantLock）和Share（共享，多个线程可同时执行，如Semaphore/CountDownLatch）。

自定义的同步器继承AQS后，只须要实现共享资源state的获取和开释形式即可，其余如线程队列的保护（如获取资源失败入队/唤醒出队等）等操作，AQS在顶层曾经实现了，

AQS代码外部提供了一系列操作锁和线程队列的办法，次要操作锁的办法蕴含以下几个：

  • compareAndSetState()：利用CAS的操作来设置state的值
  • tryAcquire(int)：独占形式获取锁。胜利则返回true，失败则返回false。
  • tryRelease(int)：独占形式开释锁。胜利则返回true，失败则返回false。
  • tryAcquireShared(int)：共享形式开释锁。正数示意失败；0示意胜利，但没有残余可用资源；负数示意胜利，且有残余资源。
  • tryReleaseShared(int)：共享形式开释锁。如果开释后容许唤醒后续期待结点返回true，否则返回false。

像ReentrantLock就是实现了自定义的tryAcquire-tryRelease，从而操作state的值来实现同步成果。

除此之外，AQS外部还定义了一个动态类Node，示意CLH队列的每一个结点，该结点的作用是对每一个期待获取资源做了封装，蕴含了须要同步的线程自身、线程期待状态.....

咱们能够看下该类的一些重点变量：

static final class Node {

    /** 示意共享模式下期待的Node */    static final Node SHARED = new Node();    /** 示意独占模式下期待的mode */    static final Node EXCLUSIVE = null;    /** 上面几个为waitStatus的具体值 */    static final int CANCELLED =  1;    static final int SIGNAL    = -1;    static final int CONDITION = -2;    static final int PROPAGATE = -3;    volatile int waitStatus;         /** 示意后面的结点 */    volatile Node prev;     /** 示意前面的结点 */    volatile Node next;     /**以后结点装载的线程，初始化时被创立，应用后会置空*/    volatile Thread thread;     /**链接到下一个节点的期待条件，用到Condition的时候会应用到*/    Node nextWaiter;}

代码外面定义了一个示意以后Node结点期待状态的字段waitStatus，该字段的取值蕴含了CANCELLED(1)、SIGNAL(-1)、CONDITION(-2)、PROPAGATE(-3)、0，这五个值代表了不同的特定场景：

  • CANCELLED：示意以后结点已勾销调度。当timeout或被中断（响应中断的状况下），会触发变更为此状态，进入该状态后的结点将不会再变动。
  • SIGNAL：示意后继结点在期待以后结点唤醒。后继结点入队时，会将前继结点的状态更新为SIGNAL（记住这个-1的值，因为前面咱们讲的时候常常会提到）
  • CONDITION：示意结点期待在Condition上，当其余线程调用了Condition的signal()办法后，CONDITION状态的结点将从期待队列转移到同步队列中，期待获取同步锁。(注：Condition是AQS的一个组件，前面会细说)
  • PROPAGATE：共享模式下，前继结点不仅会唤醒其后继结点，同时也可能会唤醒后继的后继结点。
  • 0：新结点入队时的默认状态。

也就是说，当waitStatus为负值示意结点处于无效期待状态，为正值的时候示意结点已被勾销。

在AQS外部中还保护了两个Node对象head和tail，一开始默认都为null

private transient volatile Node head;private transient volatile Node tail;

讲完了AQS的一些根底定义，咱们就能够开始学习同步的具体运行机制了，为了更好的演示，咱们用ReentrantLock作为应用入口，一步步跟进源码探索AQS底层是如何运作的，这里阐明一下，因为ReentrantLock底层调用的AQS是独占模式，所以下文解说的AQS源码也是针对独占模式的操作

好了，热身正式完结，来吧。

独占模式

加锁过程

咱们都晓得，ReentrantLock的加锁和解锁办法别离为lock()和unLock()，咱们先来看获取锁的办法，

final void lock() { if (compareAndSetState(0, 1))  setExclusiveOwnerThread(Thread.currentThread()); else  acquire(1);}

逻辑很简略，线程进来后间接利用CAS尝试抢占锁，如果抢占胜利state值回被改为1，且设置对象独占锁线程为以后线程，否则就调用acquire(1)再次尝试获取锁。

咱们假设有两个线程A和B同时竞争锁，A进来先抢占到锁，此时的AQS模型图就相似这样：

持续走上面的办法，

public final void acquire(int arg) { if (!tryAcquire(arg) &&  acquireQueued(addWaiter(Node.EXCLUSIVE), arg))  selfInterrupt();}

acquire蕴含了几个函数的调用，

tryAcquire：尝试间接获取锁，如果胜利就间接返回；

addWaiter：将该线程退出期待队列FIFO的尾部，并标记为独占模式；

acquireQueued：线程阻塞在期待队列中获取锁，始终获取到资源后才返回。如果在整个期待过程中被中断过，则返回true，否则返回false。

selfInterrupt：自我中断，就是既拿不到锁，又在期待时被中断了，线程就会进行自我中断selfInterrupt()，将中断补上。

咱们一个个来看源码，并联合下面的两个线程来做场景剖析。

tryAcquire

不必多说，就是为了再次尝试获取锁

protected final boolean tryAcquire(int acquires) { return nonfairTryAcquire(acquires);}final boolean nonfairTryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) {  if (compareAndSetState(0, acquires)) {   setExclusiveOwnerThread(current);   return true;  } } else if (current == getExclusiveOwnerThread()) {  int nextc = c + acquires;  if (nextc < 0) // overflow   throw new Error("Maximum lock count exceeded");  setState(nextc);  return true; } return false;}

当线程B进来后，nonfairTryAcquire办法首先会获取state的值，如果为0，则失常获取该锁，不为0的话判断是否是以后线程占用了，是的话就累加state的值，这里的累加也是为了配合开释锁时候的次数，从而实现可重入锁的成果。

当然，因为之前锁曾经被线程A霸占了，所以这时候tryAcquire会返回false，持续上面的流程。

addWaiter

private Node addWaiter(Node mode) { Node node = new Node(Thread.currentThread(), mode); // Try the fast path of enq; backup to full enq on failure Node pred = tail; if (pred != null) {  node.prev = pred;  if (compareAndSetTail(pred, node)) {   pred.next = node;   return node;  } } enq(node); return node;}

这段代码首先会创立一个和以后线程绑定的Node节点，Node为双向链表。此时期待队列中的tail指针为空，间接调用enq(node)办法将以后线程退出期待队列尾部，而后返回以后结点的前驱结点，

private Node enq(final Node node) { // CAS"自旋"，直到胜利退出队尾    for (;;) {        Node t = tail;        if (t == null) {         // 队列为空，初始化一个Node结点作为Head结点，并将tail结点也指向它            if (compareAndSetHead(new Node()))                tail = head;        } else {         // 把以后结点插入队列尾部            node.prev = t;            if (compareAndSetTail(t, node)) {                t.next = node;                return t;            }        }    }}

第一遍循环时，tail指针为空，初始化一个Node结点，并把head和tail结点都指向它，而后第二次循环进来之后，tail结点不为空了，就将以后的结点退出到tail结点前面，也就是这样：

todo 如果此时有另一个线程C进来的话，发现锁曾经被A拿走了，而后队列里曾经有了线程B，那么线程C就只能乖乖排到线程B的前面去，

acquireQueued

接着解读办法，通过tryAcquire()和addWaiter()，咱们的线程还是没有拿到资源，并且还被排到了队列的尾部，如果让你来设计的话，这个时候你会怎么解决线程呢？其实答案也很简略，能做的事无非两个：

1、循环让线程再抢资源。但认真一斟酌就晓得不合理，因为如果有多个线程都参加的话，你抢我也抢只会升高零碎性能

2、进入期待状态劳动，直到其余线程彻底开释资源后唤醒本人，本人再拿到资源

毫无疑问，抉择2更加靠谱，acquireQueued办法做的也是这样的解决：

final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try {  // 标记是否会被中断  boolean interrupted = false;  // CAS自旋  for (;;) {   // 获取以后结点的前结点   final Node p = node.predecessor();   if (p == head && tryAcquire(arg)) {    setHead(node);    p.next = null; // help GC    failed = false;    return interrupted;   }   if (shouldParkAfterFailedAcquire(p, node) &&    parkAndCheckInterrupt())    interrupted = true;  } } finally {  if (failed)   // 获取锁失败，则将此线程对应的node的waitStatus改为CANCEL   cancelAcquire(node); }}private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { int ws = pred.waitStatus; if (ws == Node.SIGNAL)  // 前驱结点期待状态为"SIGNAL"，那么本人就能够安心期待被唤醒了  return true; if (ws > 0) {  /*   * 前驱结点被勾销了，通过循环始终往前找，直到找到期待状态无效的结点(期待状态值小于等于0) ，   * 而后排在他们的后边，至于那些被以后Node强制"靠后"的结点，因为曾经被勾销了，也没有援用链，   * 就等着被GC了   */  do {   node.prev = pred = pred.prev;  } while (pred.waitStatus > 0);  pred.next = node; } else {  // 如果前驱失常，那就把前驱的状态设置成SIGNAL  compareAndSetWaitStatus(pred, ws, Node.SIGNAL); } return false;}private final boolean parkAndCheckInterrupt() { LockSupport.park(this); return Thread.interrupted();}

acquireQueued办法的流程是这样的：

1、CAS自旋，先判断以后传入的Node的前结点是否为head结点，是的话就尝试获取锁，获取锁胜利的话就把以后结点置为head，之前的head置为null(不便GC)，而后返回

2、如果前驱结点不是head或者加锁失败的话，就调用shouldParkAfterFailedAcquire，将前驱节点的waitStatus变为了SIGNAL=-1，最初执行parkAndChecknIterrupt办法，调用LockSupport.park()挂起以后线程，parkAndCheckInterrupt在挂起线程后会判断线程是否被中断，如果被中断的话，就会从新跑acquireQueued办法的CAS自旋操作，直到获取资源。

ps：LockSupport.park办法会让以后线程进入waitting状态，在这种状态下，线程被唤醒的状况有两种，一是被unpark()，二是被interrupt()，所以，如果是第二种状况的话，须要返回被中断的标记，而后在acquire顶层办法的窗口那里自我中断补上

此时，因为线程A还未开释锁，所以线程B状态都是被挂起的，

到这里，加锁的流程就剖析完了，其实整体来说也并不简单，而且当你了解了独占模式加锁的过程，前面开释锁和共享模式的运行机制也没什么难懂的了，所以整个加锁的过程还是有必要多消化下的，也是AQS的重中之重。

为了不便你们更加清晰了解，我加多一张流程图吧（这个作者也太暖了吧，哈哈）

开释锁

说完了加锁，咱们来看看开释锁是怎么做的，AQS中开释锁的办法是release()，当调用该办法时会开释指定量的资源 (也就是锁) ，如果彻底开释了（即state=0）,它会唤醒期待队列里的其余线程来获取资源。

还是一步步看源码吧，

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

代码上能够看出，外围的逻辑都在tryRelease办法中，该办法的作用是开释资源，AQS里该办法没有具体的实现，须要由自定义的同步器去实现，咱们看下ReentrantLock代码中对应办法的源码：

protected final boolean tryRelease(int releases) {     int c = getState() - releases;     if (Thread.currentThread() != getExclusiveOwnerThread())      throw new IllegalMonitorStateException();     boolean free = false;     if (c == 0) {      free = true;      setExclusiveOwnerThread(null);     }     setState(c);     return free;}

tryRelease办法会减去state对应的值，如果state为0，也就是曾经彻底开释资源，就返回true，并且把独占的线程置为null，否则返回false。

此时AQS中的数据就会变成这样：

齐全开释资源后，以后线程要做的就是唤醒CLH队列中第一个在期待资源的线程，也就是head结点前面的线程，此时调用的办法是unparkSuccessor()，

private void unparkSuccessor(Node node) {    int ws = node.waitStatus;    if (ws < 0)     //将head结点的状态置为0        compareAndSetWaitStatus(node, ws, 0); //找到下一个须要唤醒的结点s    Node s = node.next;    //如果为空或已勾销    if (s == null || s.waitStatus > 0) {        s = null;        // 从后向前，直到找到期待状态小于0的结点，后面说了，结点waitStatus小于0时才无效        for (Node t = tail; t != null && t != node; t = t.prev)             if (t.waitStatus <= 0)                s = t;    }    // 找到无效的结点，间接唤醒    if (s != null)        LockSupport.unpark(s.thread);//唤醒}

办法的逻辑很简略，就是先将head的结点状态置为0，防止上面找结点的时候再找到head，而后找到队列中最后面的无效结点，而后唤醒，咱们假如这个时候线程A曾经开释锁，那么此时队列中排最前边竞争锁的线程B就会被唤醒，

而后被唤醒的线程B就会尝试用CAS获取锁，回到acquireQueued办法的逻辑，

for (;;) {     // 获取以后结点的前结点     final Node p = node.predecessor();     if (p == head && tryAcquire(arg)) {      setHead(node);      p.next = null; // help GC      failed = false;      return interrupted;     }     if (shouldParkAfterFailedAcquire(p, node) &&      parkAndCheckInterrupt())      interrupted = true;}

当线程B获取锁之后，会把以后结点赋值给head，而后原先的前驱结点 (也就是原来的head结点) 去掉援用链，不便回收，这样一来，线程B获取锁的整个过程就实现了，此时AQS的数据就会变成这样：

到这里，咱们曾经剖析完了AQS独占模式下加锁和开释锁的过程，也就是tryAccquire->tryRelease这一链条的逻辑，除此之外，AQS中还反对共享模式的同步，这种模式下对于锁的操作外围其实就是tryAcquireShared->tryReleaseShared这两个办法，咱们能够简略看下

共享模式

获取锁

AQS中，共享模式获取锁的顶层入口办法是acquireShared，该办法会获取指定数量的资源，胜利的话就间接返回，失败的话就进入期待队列，直到获取资源，

public final void acquireShared(int arg) {     if (tryAcquireShared(arg) < 0)      doAcquireShared(arg);}

该办法里蕴含了两个办法的调用，

tryAcquireShared：尝试获取肯定资源的锁，返回的值代表获取锁的状态。

doAcquireShared：进入期待队列，并循环尝试获取锁，直到胜利。

tryAcquireShared

tryAcquireShared在AQS里没有实现，同样由自定义的同步器去实现具体的逻辑，像一些较为常见的并发工具Semaphore、CountDownLatch里就有对该办法的自定义实现，尽管实现的逻辑不同，但办法的作用是一样的，就是获取肯定资源的资源，而后依据返回值判断是否还有残余资源，从而决定下一步的操作。

返回值有三种定义：

  • 负值代表获取失败；
  • 0代表获取胜利，但没有残余的资源，也就是state曾经为0；
  • 正值代表获取胜利，而且state还有残余，其余线程能够持续支付

当返回值小于0时，证实此次获取肯定数量的锁失败了，而后就会走doAcquireShared办法

doAcquireShared

此办法的作用是将以后线程退出期待队列尾部劳动，直到其余线程开释资源唤醒本人，本人胜利拿到相应量的资源后才返回，这是它的源码：

private void doAcquireShared(int arg) { // 退出队列尾部 final Node node = addWaiter(Node.SHARED); boolean failed = true; try {  boolean interrupted = false;  // CAS自旋  for (;;) {   final Node p = node.predecessor();   // 判断前驱结点是否是head   if (p == head) {    // 尝试获取肯定数量的锁    int r = tryAcquireShared(arg);    if (r >= 0) {     // 获取锁胜利，而且还有残余资源，就设置以后结点为head，并持续唤醒下一个线程     setHeadAndPropagate(node, r);     // 让前驱结点去掉援用链，不便被GC     p.next = null; // help GC     if (interrupted)      selfInterrupt();     failed = false;     return;    }   }   // 跟独占模式一样，改前驱结点waitStatus为-1，并且以后线程挂起，期待被唤醒   if (shouldParkAfterFailedAcquire(p, node) &&    parkAndCheckInterrupt())    interrupted = true;  } } finally {  if (failed)   cancelAcquire(node); }}private void setHeadAndPropagate(Node node, int propagate) {    Node h = head;    // head指向本人    setHead(node);     // 如果还有残余量，持续唤醒下一个街坊线程    if (propagate > 0 || h == null || h.waitStatus < 0) {        Node s = node.next;        if (s == null || s.isShared())            doReleaseShared();    }}

看到这里，你会不会一点相熟的感觉，这个办法的逻辑怎么跟下面那个acquireQueued() 那么相似啊？对的，其实两个流程并没有太大的差异。只是doAcquireShared()比起独占模式下的获取锁上多了一步唤醒后继线程的操作，当获取完肯定的资源后，发现还有残余的资源，就持续唤醒下一个街坊线程，这才合乎"共享"的思维嘛。

这里咱们能够提出一个疑难，共享模式下，以后线程开释了肯定数量的资源，但这部分资源满足不了下一个期待结点的需要的话，那么会怎么样？

依照失常的思维，共享模式是能够多个线程同时执行的才对，所以，多个线程的状况下，如果老大开释完资源，但这部分资源满足不了老二，但能满足老三，那么老三就能够拿到资源。可事实是，从源码设计中能够看出，如果真的产生了这种状况，老三是拿不到资源的，因为期待队列是按顺序排列的，老二的资源需求量大，会把前面量小的老三以及老四、老五等都给卡住。从这一个角度来看，尽管AQS严格保障了程序，但也升高了并发能力

接着往下说吧，唤醒下一个街坊线程的逻辑在doReleaseShared()中，咱们放到上面的开释锁来解析。

开释锁

共享模式开释锁的顶层办法是releaseShared，它会开释指定量的资源，如果胜利开释且容许唤醒期待线程，它会唤醒期待队列里的其余线程来获取资源。上面是releaseShared()的源码：

public final boolean releaseShared(int arg) {     if (tryReleaseShared(arg)) {      doReleaseShared();      return true;     }     return false;}

该办法同样蕴含两局部的逻辑：

tryReleaseShared：开释资源。

doAcquireShared：唤醒后继结点。

跟tryAcquireShared办法一样，tryReleaseShared在AQS中没有具体的实现，由子同步器本人去定义，但性能都一样，就是开释肯定数量的资源。

开释完资源后，线程不会马上就出工，而是唤醒期待队列里最前排的期待结点。

doAcquireShared

唤醒后继结点的工作在doReleaseShared()办法中实现，咱们能够看下它的源码：

private void doReleaseShared() {     for (;;) {      // 获取期待队列中的head结点      Node h = head;      if (h != null && h != tail) {       int ws = h.waitStatus;       // head结点waitStatus = -1,唤醒下一个结点对应的线程       if (ws == Node.SIGNAL) {        if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))         continue;            // loop to recheck cases        // 唤醒后继结点        unparkSuccessor(h);       }       else if (ws == 0 &&          !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))        continue;                // loop on failed CAS      }      if (h == head)                   // loop if head changed       break;     }}

代码没什么特地的，就是如果期待队列head结点的waitStatus为-1的话，就间接唤醒后继结点，唤醒的办法unparkSuccessor()在下面曾经讲过了，这里也没必要再复述。

总的来看，AQS共享模式的运作流程和独占模式很类似，只有把握了独占模式的流程运行，共享模式什么的不就那样吗，没难度。这也是我为什么共享模式解说中不画流程图的起因，没必要嘛。

Condition

介绍完了AQS的外围性能，咱们再扩大一个知识点，在AQS中，除了提供独占/共享模式的加锁/解锁性能，它还对外提供了对于Condition的一些操作方法。

Condition是个接口，在jdk1.5版本后设计的，根本的办法就是await()和signal()办法，性能大略就对应Object的wait()和notify()，Condition必须要配合锁一起应用，因为对共享状态变量的拜访产生在多线程环境下。一个Condition的实例必须与一个Lock绑定，因而Condition个别都是作为Lock的外部实现 ，AQS中就定义了一个类ConditionObject来实现了这个接口，

那么它应该怎么用呢？咱们能够简略写个demo来看下成果

public class ConditionDemo {    public static void main(String[] args) {        ReentrantLock lock = new ReentrantLock();        Condition condition = lock.newCondition();        Thread tA = new Thread(() -> {            lock.lock();            try {                System.out.println("线程A加锁胜利");                System.out.println("线程A执行await被挂起");                condition.await();                System.out.println("线程A被唤醒胜利");            } catch (InterruptedException e) {                e.printStackTrace();            } finally {                lock.unlock();                System.out.println("线程A开释锁胜利");            }        });        Thread tB = new Thread(() -> {            lock.lock();            try {                System.out.println("线程B加锁胜利");                condition.signal();                System.out.println("线程B唤醒线程A");            } finally {                lock.unlock();                System.out.println("线程B开释锁胜利");            }        });        tA.start();        tB.start();    }}

执行main函数后后果输入为：

线程A加锁胜利
线程A执行await被挂起
线程B加锁胜利
线程B唤醒线程A
线程B开释锁胜利
线程A被唤醒胜利
线程A开释锁胜利

代码执行的后果很容易了解，线程A先获取锁，而后调用await()办法挂起以后线程并开释锁，线程B这时候拿到锁，而后调用signal唤醒线程A。

毫无疑问，这两个办法让线程的状态产生了变动，咱们认真来钻研一下，

翻看AQS的源码，咱们会发现Condition中定义了两个属性firstWaiter和lastWaiter，后面说了，AQS中蕴含了一个FIFO的CLH期待队列，每个Conditon对象就蕴含这样一个期待队列，而这两个属性别离示意的是期待队列中的首尾结点，

/** First node of condition queue. */private transient Node firstWaiter;/** Last node of condition queue. */private transient Node lastWaiter;

留神：Condition当中的期待队列和AQS主体的同步期待队列是离开的，两个队列尽管构造体雷同，然而作用域是离开的

await

先看await()的源码：

public final void await() throws InterruptedException {    if (Thread.interrupted())        throw new InterruptedException();    // 将以后线程退出到期待队列中    Node node = addConditionWaiter();    // 齐全开释占有的资源，并返回资源数    int savedState = fullyRelease(node);    int interruptMode = 0;    // 循环判断以后结点是不是在Condition的队列中，是的话挂起    while (!isOnSyncQueue(node)) {        LockSupport.park(this);        if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)            break;    }    if (acquireQueued(node, savedState) && interruptMode != THROW_IE)        interruptMode = REINTERRUPT;    if (node.nextWaiter != null) // clean up if cancelled        unlinkCancelledWaiters();    if (interruptMode != 0)        reportInterruptAfterWait(interruptMode);}

当一个线程调用Condition.await()办法，将会以以后线程结构结点，这个结点的waitStatus赋值为Node.CONDITION，也就是-2，并将结点从尾部退出期待队列，而后尾部结点就会指向这个新增的结点，

private Node addConditionWaiter() {    Node t = lastWaiter;    // If lastWaiter is cancelled, clean out.    if (t != null && t.waitStatus != Node.CONDITION) {        unlinkCancelledWaiters();        t = lastWaiter;    }    Node node = new Node(Thread.currentThread(), Node.CONDITION);    if (t == null)        firstWaiter = node;    else        t.nextWaiter = node;    lastWaiter = node;    return node;}

咱们仍然用下面的demo来演示，此时，线程A获取锁并调用Condition.await()办法后，AQS外部的数据结构会变成这样：

在Condition队列中插入对应的结点后，线程A会开释所持有的资源，走到while循环那层逻辑，

while (!isOnSyncQueue(node)) {
LockSupport.park(this);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}

isOnSyncQueue办法的会判断以后的线程节点是不是在同步队列中，这个时候此结点还在Condition队列中，所以该办法返回false，这样的话循环会始终继续上来，线程被挂起，期待被唤醒，此时，线程A的流程临时进行了。

当线程A调用await()办法挂起的时候，线程B获取到了线程A开释的资源，而后执行signal()办法：

signal

public final void signal() {    if (!isHeldExclusively())        throw new IllegalMonitorStateException();    Node first = firstWaiter;    if (first != null)        doSignal(first);}

先判断以后线程是否为获取锁的线程，如果不是则间接抛出异样。 接着调用doSignal()办法来唤醒线程。

private void doSignal(Node first) { // 循环，从队列始终往后找不为空的首结点    do {        if ( (firstWaiter = first.nextWaiter) == null)            lastWaiter = null;        first.nextWaiter = null;    } while (!transferForSignal(first) &&             (first = firstWaiter) != null);}final boolean transferForSignal(Node node) { // CAS循环，将结点的waitStatus改为0    if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))        return false; // 下面曾经剖析过，此办法会把以后结点退出到期待队列中，并返回前驱结点    Node p = enq(node);    int ws = p.waitStatus;    if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))        LockSupport.unpark(node.thread);    return true;}

从doSignal的代码中能够看出，这时候程序寻找的是Condition期待队列中首结点firstWaiter的结点，此时该结点指向的是线程A的结点，所以之后的流程作用的都是线程A的结点。

这里剖析下transferForSignal办法，先通过CAS自旋将结点waitStatus改为0，而后就把结点放入到同步队列 (此队列不是Condition的期待队列) 中，而后再用CAS将同步队列中该结点的前驱结点waitStatus改为Node.SIGNAL，也就是-1，此时AQS的数据结构大略如下 (额.....少画了个箭头，大家就当head结点是线程A结点的前驱结点就好)：

回到await()办法，当线程A的结点被退出同步队列中时，isOnSyncQueue()会返回true，跳出循环，

while (!isOnSyncQueue(node)) {        LockSupport.park(this);        if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)            break;    }    if (acquireQueued(node, savedState) && interruptMode != THROW_IE)        interruptMode = REINTERRUPT;    if (node.nextWaiter != null) // clean up if cancelled        unlinkCancelledWaiters();    if (interruptMode != 0)        reportInterruptAfterWait(interruptMode);

接着执行acquireQueued()办法，这里就不必多说了吧，尝试从新获取锁，如果获取锁失败持续会被挂起，直到另外线程开释锁才被唤醒。

所以，当线程B开释完锁后，线程A被唤醒，持续尝试获取锁，至此流程完结。

对于这整个通信过程，咱们能够画一张流程图展现下：

总结

说完了Condition的应用和底层运行机制，咱们再来总结下它跟一般 wait/notify 的比拟，个别这也是问的比拟多的，Condition大略有以下两点劣势：

  • Condition 须要联合 Lock 进行管制，应用的时候要留神肯定要对应的unlock()，能够对多个不同条件进行管制，只有new 多个 Condition对象就能够为多个线程管制通信，wait/notify 只能和 synchronized 关键字一起应用，并且只能唤醒一个或者全副的期待队列；
  • Condition 有相似于 await 的机制，因而不会产生加锁形式而产生的死锁呈现，同时底层实现的是 park/unpark 的机制，因而也不会产生先唤醒再挂起的死锁，一句话就是不会产生死锁，然而 wait/notify 会产生先唤醒再挂起的死锁。

最初

对AQS的源码剖析到这里就全副完结了，尽管还有很多知识点没解说，比方偏心锁/非偏心锁下AQS是怎么作用的，篇幅所限，局部知识点没有扩大还请见谅，尽管如此，如果您能看完文章的话，置信对AQS也算是有足够的理解了。

回顾本篇文章，咱们不难发现，无论是独占还是共享模式，或者联合是Condition工具应用，AQS实质上的同步性能都是通过对锁和队列中结点的操作来实现的，从设计上讲，AQS的组成构造并不算简单，底层的运行机制也不会很绕，所以，大家如果看源码的时候感觉有些艰难的话也不必灰心，多看几遍，顺便画个图之类的，理清下流程还是没什么问题的。

当然，本人看得懂是一回事，写进去让他人看懂又是另一回事了，就像这篇文章，我花了好长的工夫来筹备，又是画图又是理流程的，期间还参考了不少网上大神的博文，肝了几天才算是成文了。尽管我晓得本文不算什么高质文，但我也算是费尽心力了，写技术文真是挺累的，大家看的感觉不错的话还请帮忙转发下或点个赞吧！这也是对我最好的激励了

作者：鄙人薛某，一个不拘于技术的互联网人，技术三流，吹水一流，想看更多精彩文章能够关注我的公众号哦~~~