Java多线程之六：AQS
什么是AQS
AQS（AbstractQueuedSynchronizer）是JDK下提供的一套用于实现基于FIFO等待队列的阻塞锁和相关的同步器的一个同步框架。这个抽象类被设计为作为一些可用原子int（private volatile int state）值来表示状态的同步器的基类(如：独占锁。1代表已占有，0代表未占有)。比如我们提到的ReentrantLock，CountDownLatch，Semaphore，其他的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的，如CountDownLatch其内部有一个继承了 AbstractQueuedSynchronizer 的内部类 Sync，这些类里面都维护了一套aqs的子类，利用子类实现的功能。该队列里面维护的是一堆线程节点。核心思想是当前线程获取锁的时候如果失败了，就被加入到阻塞队列中（fifo双向队列）配合锁一起使用的。主要关注getstate().setstate(),compareandsetstate(int expect,int update)当状态值为0的时候说明没有线程获取锁，否则有线程获取锁，在此当中在判断是不是当前线程，（可重入锁的特性）可重入锁可以设置公平锁和非公平锁，非公平锁需要进行2次的cas然后在进入队列，公平锁是看一下对列里面是否有排队的线程，有的话直接添加到队列的尾部排队。CountDownLatch 调用 await() 方法时，先去获取 state 的值，当计数器不为0的时候，说明还有需要等待的线程在运行，则调用 doAcquireSharedInterruptibly 方法，进来执行的第一个动作就是尝试加入等待队列 ，即调用 addWaiter（）方法，await() 方法是线程阻塞，直到计数器为0，才会启动。
AQS还定义了一个实现了Condition接口的ConditionObject内部类。Condition 将 Object 监视器方法（wait、notify 和 notifyAll）分解成截然不同的对象，以便通过将这些对象与任意 Lock 实现组合使用，为每个对象提供多个等待 set （wait-set）。其中，Lock 替代了 synchronized 方法和语句的使用，Condition 替代了 Object 监视器方法的使用。
简单来说，就是Condition提供类似于Object的wait、notify的功能signal和await，都是可以使一个正在执行的线程挂起（推迟执行），直到被其他线程唤醒。但是Condition更加强大，如支持多个条件谓词、保证线程唤醒的顺序和在挂起时不需要拥有锁。关于Condition更加详细的资料可以看这里
如上所述，AQS管理一个关于状态信息的单一整数，该整数可以表现任何状态。比如， Semaphore 用它来表现剩余的许可数，ReentrantLock 用它来表现拥有它的线程已经请求了多少次锁；FutureTask 用它来表现任务的状态(尚未开始、运行、完成和取消)。
注：CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS是将每条请求共享资源的线程封装成一个CLH锁队列的一个结点（Node）来实现锁的分配。
AQS中概念
1、AQS定义两种资源共享方式：Exclusive（独占）和Share（共享）
Exclusive：只有一个线程能执行，如ReentrantLock。
又可分为 公平锁和非公平锁:
公平锁：按照线程在队列中的排队顺序，先到者先拿锁
非公平锁：当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的
- 判断能否获取同步状态需要子类去实现模板方法tryAcquire;
- 判断能欧服释放同步状态需要子类去实现模板方法tryRelease。
Share：多个线程可同时执行，如Semaphore/ConutDownLatch。
- 判断能否获取同步状态需要子类去实现模板方法tryAcquireShared;
- 判断能否释放同步状态需要子类去是吸纳模板方法tryReleaseShared。
不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源state的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在顶层实现好了.
AQS使用了模板方法模式，如果需要自定义同步器一般的方式是这样（模板方法模式很经典的一个应用）：
- 使用者继承AbstractQueuedSynchronizer并重写指定的方法。（这些重写方法很简单，无非是对于共享资源state的获取和释放）
- 将AQS组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。
自定义同步器实现时主要重写以下几个AQS提供的模板方法：
- isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
- tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
- tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
- tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
- tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。
默认情况下，每个方法都抛出 UnsupportedOperationException。 这些方法的实现必须是内部线程安全的，并且通常应该简短而不是阻塞。AQS类中的其他方法都是final ，所以无法被其他类使用，只有这几个方法可以被其他类使用。
以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。
再以CountDownLatch以例，任务分为N个子线程去执行，state也初始化为N（注意N要与线程个数一致）。这N个子线程是并行执行的，每个子线程执行完后countDown()一次，state会CAS(Compare and Swap)减1。等到所有子线程都执行完后(即state=0)，会unpark()主调用线程，然后主调用线程就会从await()函数返回，继续后余动作。
一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。
2、同步状态
AQS使用一个int类型的成员变量state来表示同步状态，AQS的是夏磊重写模板方法，在其中运用此变量作为是否能够获取锁的依据。
state：
/** * The synchronization state.代表共享资源 */ private volatile int state; /** * Returns the current value of synchronization state. * This operation has memory semantics of a {@code volatile} read. * @return current state value */ protected final int getState() { return state; } /** * Sets the value of synchronization state. * This operation has memory semantics of a {@code volatile} write. * @param newState the new state value */ protected final void setState(int newState) { state = newState; } /** * Atomically sets synchronization state to the given updated * value if the current state value equals the expected value. * This operation has memory semantics of a {@code volatile} read * and write. * * @param expect the expected value * @param update the new value * @return {@code true} if successful. False return indicates that the actual * value was not equal to the expected value. */ protected final boolean compareAndSetState(int expect, int update) { // See below for intrinsics setup to support this return unsafe.compareAndSwapInt(this, stateOffset, expect, update); }
3、同步队列
同步队列又被称为CLH队列，CLH队列是一个通过链式方式实现FIFO双向队列，AQS依赖它来完成同步状态的管理。当线程获取同步状态失败时，AQS则会将当前线程构造成一个节点（Node）并将其加入到CLH同步队列【节点会按照同步状态方式不同产生不同类型的节点】，同时会阻塞当前线程，当同步状态被释放时，会把节点后第一个节点的线程从阻塞状态唤醒，唤醒的线程会尝试竞争同步状态，如果能获取同步状态成功，则从同步队列中出队。
示例：
package main.concurrent;import java.util.Date; import java.util.concurrent.locks.ReentrantLock; public class AqsDemoTest { private static ReentrantLock lock = new ReentrantLock(); public static void main(String[] args) { for(int i = 0; i <5 ; i ++){ try{ System.out.println("i = " + i + " start, ThreadName="+Thread.currentThread().getName() + " " + new Date()); Thread.sleep(2000); }catch (Exception e){ e.printStackTrace(); } Thread thread = new Thread(() ->{ System.out.println("start get lock ThreadName="+Thread.currentThread().getName() + " " + new Date()); lock.lock(); System.out.println("after get lock ThreadName="+Thread.currentThread().getName() + " " + new Date()); try{ Thread.sleep(10000); }catch (Exception e){ e.printStackTrace(); }finally { lock.unlock(); System.out.println("unlock ThreadName="+Thread.currentThread().getName() + " " + new Date()); } }); thread.start(); } } }
实例代码中开启了5个线程，先获取锁之后再睡眠10S中，实际上这里让线程睡眠是想模拟出当线程无法获取锁时进入同步队列的情况。通过debug，当Thread-4（在本例中最后一个线程）获取锁失败后进入同步时，AQS时现在的同步队列如图所示
运行结果：
i = 0 start, ThreadName=main Tue Jun 25 14:52:43 CST 2019 i = 1 start, ThreadName=main Tue Jun 25 14:52:45 CST 2019 start get lock ThreadName=Thread-0 Tue Jun 25 14:52:45 CST 2019 after get lock ThreadName=Thread-0 Tue Jun 25 14:52:45 CST 2019 i = 2 start, ThreadName=main Tue Jun 25 14:52:47 CST 2019 start get lock ThreadName=Thread-1 Tue Jun 25 14:52:47 CST 2019 i = 3 start, ThreadName=main Tue Jun 25 14:52:49 CST 2019 start get lock ThreadName=Thread-2 Tue Jun 25 14:52:49 CST 2019 i = 4 start, ThreadName=main Tue Jun 25 14:52:51 CST 2019 start get lock ThreadName=Thread-3 Tue Jun 25 14:52:51 CST 2019 start get lock ThreadName=Thread-4 Tue Jun 25 14:52:53 CST 2019 unlock ThreadName=Thread-0 Tue Jun 25 14:52:55 CST 2019 after get lock ThreadName=Thread-1 Tue Jun 25 14:52:55 CST 2019 unlock ThreadName=Thread-1 Tue Jun 25 14:53:05 CST 2019 after get lock ThreadName=Thread-2 Tue Jun 25 14:53:05 CST 2019 unlock ThreadName=Thread-2 Tue Jun 25 14:53:15 CST 2019 after get lock ThreadName=Thread-3 Tue Jun 25 14:53:15 CST 2019 unlock ThreadName=Thread-3 Tue Jun 25 14:53:25 CST 2019 after get lock ThreadName=Thread-4 Tue Jun 25 14:53:25 CST 2019 unlock ThreadName=Thread-4 Tue Jun 25 14:53:35 CST 2019
4、Condition&等待队列
- Condition即“条件”，是一个接口，它提供了和Java传统的监视器风格的wait、notify、notifyAll方法类似功能的方法awailt()、signal()、sianalAll()的方法。
- AQS内部存在一个内部类实现了Condition接口，通过一个链式方式实现单向等待队列实现了锁等待和锁释放的功能，并在此扩展出了超市等待，定时等待的共呢个的方法awaitNanos(),awaitUntil()。
核心逻辑如下:
- 当获取同步状态的线程调用condition.await(),则会阻塞,并进入一个等待队列,释放同步状态.
- 当其他线程调用了condition.signal()方法,会从等待队列firstWaiter开始选择第一个等待状态不是取消的节点.添加到同步队列尾部.
- 当其他线程调用了condition.signalAll()方法,会从等待队列firstWaiter开始选择所有等待状态不是取消的节点.添加到同步队列尾部.
示例：
public static void main(String[] args) { for (int i = 0; i < 10; i++) { Thread thread = new Thread(() -> { lock.lock(); try { condition.await(); } catch (InterruptedException e) { e.printStackTrace(); }finally { lock.unlock(); } }); thread.start(); } }
新建了10个线程，每个线程先获取锁，然后调用condition.await方法释放锁将当前线程加入到等待队列中，通过debug控制当走到第10个线程的时候查看firstWaiter即等待队列中的头结点，debug模式下情景图如下
5、CLH同步队列节点和等待队列节点
AQS 内部提供了一个内部类.用来作为同步队列和等待队列的节点对象.需要注意作为不同队列的节点.其使用的属性和含义是不同的。
/** +------+ prev +-----+ +-----+ head | | <---- | | <---- | | tail +------+ +-----+ +-----+ /** static final class Node { /** 共享 SHARED作为共享模式下的常量*/ static final Node SHARED = new Node(); /** 独占 EXCLUSIVE作为独占模式下的常量*/ static final Node EXCLUSIVE = null; /** * 双向同步队列节点时使用，因为超时或者中断，节点会被设置为取消状态，被取消的节点时不会参与到竞争中的，他会一直保持取消状态不会转变为其他状态； */ static final int CANCELLED = 1; /** * 双向同步队列节点时使用，后继节点的线程处于等待状态. * 而当前节点的线程如果释放了同步状态或者被取消，将会通知后继节点，使后继节点的线程得以运行 */ static final int SIGNAL = -1; /** * 单向等待队列节点时使用,等待节点需要被唤醒 */ static final int CONDITION = -2; /** * 双向同步队列节点时使用,共享模式释放时，会将节点设置为此状态，并一直传播通知后续节点停止阻塞。尝试获取锁。 */ static final int PROPAGATE = -3; /** * 等待状态 只具有以下值 * SIGNAL: 当前节点的后继节点已经 (或即将)被阻塞（通过park） , * 所以当 当前节点释放或则被取消时候 ，一定要unpark它的后继节点。为了避免竞争，获取方法一定要首先设置node为signal， * 然后再次重新调用获取方法，如果失败，则阻塞 * CANCELLED: 当前节点由于超时或者被中断而被取消。一旦节点被取消后，那么它的状态值不在会被改变，且当前节点的线程不会再次被阻塞 * CONDITION: 表示当前节点正在条件队列（AQS下的ConditionObject里也维护了个队列）中， * 在从conditionObject队列转移到同步队列前，它不会在同步队列（AQS下的队列）中被使用。 * 当成功转移后，该节点的状态值将由CONDITION设置为0 * PROPAGATE: 共享模式下的释放操作应该被传播到其他节点。该状态值在doReleaseShared方法中被设置的， * * 0: 以上都不是 * * 该状态值为了简便使用，所以使用了数值类型。非负数值意味着该节点不需要被唤醒。所以，大多数代码中不需要检查该状态值的确定值, * 只需要根据正负值来判断即可对于一个正常的Node，他的waitStatus初始化值时0. * 对于一个condition队列中的Node，他的初始化值时CONDITION * 如果想要修改这个值，可以使用AQS提供CAS进行修改 */ volatile int waitStatus; /** * 双向同步队列节点时使用，前置节点指针 * 指向当前节点的前驱节点，当前节点依赖前驱节点来检测waitStatus，前驱节点是在当前节点入队时候被设置的。 * 为了提高GC效率，在当前节点出队时候会把前驱节点设置为null。而且，在取消前驱节点中，则会循环直到找到一个非取消的节点， * 由于头节点永远不会是取消状态，所以一定能找到。 */ volatile Node prev; /** * 双向同步队列节点时使用，后置节点指针 * 指向当前节点的后继节点，在当前节点释放时候会唤醒后继节点。该后继节点也是在入队时候被分配的。 * 当前驱节点被取消时候，会重新调整链表的节点链接指向关系。如：前驱节点的前驱节点指向当前节点。 * 且把前驱节点设置为null。节点入队操作过程完成前，入队操作并还未设置前驱节点的后继节点。所以 * 会看到前驱节点的后继节点为null，但是这并不意味着前驱节点就是队列的尾节点！如果后继节点为null， * 我们可以通过从尾节点向前扫描来做双重检测。一个被取消的节点的后继节点被设置为自身。即node.next=node。 * 这样设置会帮助isOnSyncQueue的执行效率更高（即执行时间更短。注意该方法的if (node.next != null)） */ volatile Node next; /** * 获取同步状态的线程 * 当前节点的线程。在构造Node时候被初始化，在节点使用完毕后设置为null * construction and nulled out after use. */ volatile Thread thread; /** * 单项等待队列节点时使用，后置节点指针 * ConditionObject链表的后继节点或者代表共享模式的节点SHARED。Condition条件队列：因为Condition队列只能在独占模式下被能被访问, * 我们只需要简单的使用链表队列来链接正在等待条件的节点。再然后它们会被转移到同步队列（AQS队列）再次重新获取。 * 由于条件队列只能在独占模式下使用，所以我们要表示共享模式的节点的话只要使用特殊值SHARED来标明即可。 */ Node nextWaiter; //是否时CLH队列的节点同时时共享式获取同步状态 final boolean isShared() { return nextWaiter == SHARED; } //获取当前节点的前置节点 final Node predecessor() throws NullPointerException { Node p = prev; if (p == null) throw new NullPointerException(); else return p; } Node() { } //创建同步队列节点,node传入Node.SHARED或Node.EXCLUSIVE Node(Thread thread, Node mode) { this.nextWaiter = mode; this.thread = thread; } //创建等待队列节点，waitStatus传入Node.CONDITION Node(Thread thread, int waitStatus) { this.waitStatus = waitStatus; this.thread = thread; } }
AQS实现原理
- AQS核心属性是一个int类型的成员变量state来表示同步状态，以及两个队列，CLH同步队列和等待队列构成。我们可以编写自己类继承AQS选择重写独占式或共享式模板方法,从而定义如何获取同步状态和释放同步状态的逻辑。无论独占式还时共享式获取同步状态成功则直接返回，失败则进入CLH同步队列并阻塞当前线程。当获取同步状态线程释放同步状态，AQS会选择从CLH队列head头部节点的第一个节点释放阻塞，尝试重写竞争获取同步状态，如果成功则将当前节点出队。如果失败则继续阻塞。
- 获取同步状态的线程也可以使用condition对象释放同步状态进入等待队列。只有等待其他线程使用condition.signal或condition.signAll()唤醒被从阻塞状态中释放重新竞争获取同步状态成功后从原来指令位置继续运行。
AQS核心方法
1、acquire(int)
独占式获取共享资源，如果当前线程获取资源态成功则直接返回，如果获取失败则线程阻塞，并插入同步队列进行.当调用release释放同步状态时，会从head头部后第一个节点中线程从阻塞中释放并在自旋中重新竞争资源，如果获取成功则出队。且整个过程忽略中断的影响。这也正是lock()的语义，当然不仅仅只限于lock()。获取到资源后，线程就可以去执行其临界区代码了。
1 public final void acquire(int arg) { 2 if (!tryAcquire(arg) && 3 acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) 4 selfInterrupt(); 5 }
函数流程如下：
- tryAcquire()尝试直接去获取资源，如果成功则直接返回；
- addWaiter()将该线程加入等待队列的尾部，并标记为独占模式；
- acquireQueued()使线程在等待队列中获取资源，一直获取到资源后才返回。如果在整个等待过程中被中断过，则返回true，否则返回false。
- 如果线程在等待过程中被中断过，它是不响应的。只是获取资源后才再进行自我中断selfInterrupt()，将中断补上。
2、 tryAcquire(int)
此方法尝试去获取独占资源。如果获取成功，则直接返回true，否则直接返回false。这也正是tryLock()的语义，还是那句话，当然不仅仅只限于tryLock()。
1 protected boolean tryAcquire(int arg) { 2 throw new UnsupportedOperationException(); 3 }
此处直接throw异常的， 还记得概述里讲的AQS只是一个框架，具体资源的获取/释放方式交由自定义同步器去实现吗？就是这里了！！！AQS这里只定义了一个接口，具体资源的获取交由自定义同步器去实现了（通过state的get/set/CAS）！！！至于能不能重入，能不能加塞，那就看具体的自定义同步器怎么去设计了！！！当然，自定义同步器在进行资源访问时要考虑线程安全的影响。
这里之所以没有定义成abstract，是因为独占模式下只用实现tryAcquire-tryRelease，而共享模式下只用实现tryAcquireShared-tryReleaseShared。如果都定义成abstract，那么每个模式也要去实现另一模式下的接口。
调用场景：
- 1 在acquire内部判断获取同步状态时调用
- 2 在release方法释放同步状态后，同步队列线程从阻塞中被唤醒，重新尝试获取同步状态时调用。
3、 addWaiter(Node)
此方法用于将当前线程加入到等待队列的队尾，并返回当前线程所在的结点。还是上源码吧：
1 private Node addWaiter(Node mode) { 2 //以给定模式构造结点。mode有两种：EXCLUSIVE（独占）和SHARED（共享） 3 Node node = new Node(Thread.currentThread(), mode); 4 5 //尝试快速方式直接放到队尾，即无竞争条件下肯定成功。如果失败，则进入enq自旋重试入队。 6 Node pred = tail; 7 if (pred != null) { 8 node.prev = pred; 9 //CAS替换当前尾部。成功则返回 10 if (compareAndSetTail(pred, node)) { 11 pred.next = node; 12 return node; 13 } 14 } 15 16 //上一步失败则通过enq入队。 17 enq(node); 18 return node; 19 }
不用再说了，直接看注释吧。这里我们说下Node。Node结点是对每一个访问同步代码的线程的封装，其包含了需要同步的线程本身以及线程的状态，如是否被阻塞，是否等待唤醒，是否已经被取消等。变量waitStatus则表示当前被封装成Node结点的等待状态，共有4种取值CANCELLED、SIGNAL、CONDITION、PROPAGATE。
-
CANCELLED：值为1，在同步队列中等待的线程等待超时或被中断，需要从同步队列中取消该Node的结点，其结点的waitStatus为CANCELLED，即结束状态，进入该状态后的结点将不会再变化。
-
SIGNAL：值为-1，被标识为该等待唤醒状态的后继结点，当其前继结点的线程释放了同步锁或被取消，将会通知该后继结点的线程执行。说白了，就是处于唤醒状态，只要前继结点释放锁，就会通知标识为SIGNAL状态的后继结点的线程执行。
-
CONDITION：值为-2，与Condition相关，该标识的结点处于等待队列中，结点的线程等待在Condition上，当其他线程调用了Condition的signal()方法后，CONDITION状态的结点将从等待队列转移到同步队列中，等待获取同步锁。
-
PROPAGATE：值为-3，与共享模式相关，在共享模式中，该状态标识结点的线程处于可运行状态。
-
0状态：值为0，代表初始化状态。
AQS在判断状态时，通过用waitStatus>0表示取消状态，而waitStatus<0表示有效状态。
4、enq(Node)
此方法用于将node加入队尾。源码如下：
private Node enq(final Node node) { //CAS"自旋"，直到成功加入队尾 for (;;) { Node t = tail; if (t == null) { // 队列为空，创建一个空的标志结点作为head结点，并将tail也指向它。 if (compareAndSetHead(new Node())) tail = head; } else {//正常流程，放入队尾 node.prev = t; if (compareAndSetTail(t, node)) { t.next = node; return t; } } } }
如果你看过AtomicInteger.getAndIncrement()函数源码，那么相信你一眼便看出这段代码的精华。CAS自旋volatile变量，是一种很经典的用法。还不太了解的，自己去百度一下吧。
5、 acquireQueued(Node, int)
OK，通过tryAcquire()和addWaiter()，该线程获取资源失败，已经被放入等待队列尾部了。聪明的你立刻应该能想到该线程下一部该干什么了吧：进入等待状态休息，直到其他线程彻底释放资源后唤醒自己，自己再拿到资源，然后就可以去干自己想干的事了。没错，就是这样！是不是跟医院排队拿号有点相似~~acquireQueued()就是干这件事：在等待队列中排队拿号（中间没其它事干可以休息），直到拿到号后再返回。这个函数非常关键，还是上源码吧：
final boolean acquireQueued(final Node node, int arg) { boolean failed = true;//标记是否成功拿到资源 try { boolean interrupted = false;//标记等待过程中是否被中断过 //又是一个“自旋”！ for (;;) { final Node p = node.predecessor();//获取当前节点的前驱节点。 //如果前驱节点是头节点且尝试获取成功，则替换当前节点会链表的头结点，然后返回 //问题：为什么是前驱节点而不是当前节点？因为我们队列在初始化时候生成了个虚拟头节点，相当于多出来了个节点。 if (p == head && tryAcquire(arg)) { setHead(node);//拿到资源后，将head指向该结点。所以head所指的标杆结点，就是当前获取到资源的那个结点或null。 p.next = null; // setHead中node.prev已置为null，此处再将head.next置为null，就是为了方便GC回收以前的head结点。也就意味着之前拿完资源的结点出队了！ failed = false; return interrupted;//返回等待过程中是否被中断过 } //判断当前节点的线程是否应该被挂起，如果应该被挂起则挂起。等待release唤醒释放 //问题：为什么要挂起当前线程？因为如果不挂起的话，线程会一直抢占着CPU if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true;//如果等待过程中被中断过，哪怕只有那么一次，就将interrupted标记为true } } finally { if (failed) //在队列中取消当前节点 cancelAcquire(node); } }
到这里了，我们先不急着总结acquireQueued()的函数流程，先看看shouldParkAfterFailedAcquire()和parkAndCheckInterrupt()具体干些什么。
6、shouldParkAfterFailedAcquire(Node, Node)
此方法主要用于检查状态，看看自己是否真的可以去休息了（进入waiting状态，如果线程状态转换不熟，可以参考Thread详解），万一队列前边的线程都放弃了只是瞎站着，那也说不定，对吧！
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { int ws = pred.waitStatus;//拿到前驱的状态 //该节点如果状态如果为SIGNAL。则返回true，然后park挂起线程 if (ws == Node.SIGNAL) //如果已经告诉前驱拿完号后通知自己一下，那就可以安心休息了 return true; //表明该节点已经被取消，向前循环重新调整链表节点 if (ws > 0) { /* * 如果前驱放弃了，那就一直往前找，直到找到最近一个正常等待的状态，并排在它的后边。 * 注意：那些放弃的结点，由于被自己“加塞”到它们前边，它们相当于形成一个无引用链，稍后就会被保安大叔赶走了(GC回收)！ */ do { node.prev = pred = pred.prev; } while (pred.waitStatus > 0); pred.next = node; } else { //执行到这里代表节点是0或者PROPAGATE，然后标记他们为SIGNAL，但是 //还不能park挂起线程。需要重试是否能获取，如果不能则挂起 compareAndSetWaitStatus(pred, ws, Node.SIGNAL); } return false; }
整个流程中，如果前驱结点的状态不是SIGNAL，那么自己就不能安心去休息，需要去找个安心的休息点，同时可以再尝试下看有没有机会轮到自己拿号。
7、parkAndCheckInterrupt()
挂起当前线程，且返回线程的中断状态。
private final boolean parkAndCheckInterrupt() { LockSupport.park(this);//调用park()使线程进入waiting状态 return Thread.interrupted();//如果被唤醒，查看自己是不是被中断的。 }
park()会让当前线程进入waiting状态。在此状态下，有两种途径可以唤醒该线程：1）被unpark()；2）被interrupt()。（再说一句，如果线程状态转换不熟，可以参考本人写的Thread详解）。需要注意的是，Thread.interrupted()会清除当前线程的中断标记位。
小结一下：
看了shouldParkAfterFailedAcquire()和parkAndCheckInterrupt()，现在让我们再回到acquireQueued()，总结下该函数的具体流程：
- 结点进入队尾后，检查状态，找到安全休息点；
- 调用park()进入waiting状态，等待unpark()或interrupt()唤醒自己；
- 被唤醒后，看自己是不是有资格能拿到号。如果拿到，head指向当前结点，并返回从入队到拿到号的整个过程中是否被中断过；如果没拿到，继续流程1。
acquireQueued()分析完之后，我们再回到acquire()！看看它的源码吧：
/** * 忽略中断的（即不手动抛出InterruptedException异常）独占模式下的获取方法。该方法在成功返回前至少 * 会调用一次tryAcquire()方法(该方法是子类重写的方法，如果返回true则代表能成功获取).否则当前线程会进入 * 队列排队，重复的阻塞和唤醒等待再次成功获取后返回, 该方法可以用来实现Lock.lock * * @param arg 这个值被传递给tryAcquire使用，主要是用来作为state值处理的参数。可以根据需要灵活使用该值 */ public final void acquire(int arg) { //首先调用tryAcquire(arg)值尝试获取，如果成功则返回true。!true则等于false不需要进入 acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) //进行排队等待再次成功获取 if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }
再来总结下它的流程吧：
- 调用自定义同步器的tryAcquire()尝试直接去获取资源，如果成功则直接返回；
- 没成功，则addWaiter()将该线程加入等待队列的尾部，并标记为独占模式；
- acquireQueued()使线程在等待队列中休息，有机会时（轮到自己，会被unpark()）会去尝试获取资源。获取到资源后才返回。如果在整个等待过程中被中断过，则返回true，否则返回false。
- 如果线程在等待过程中被中断过，它是不响应的。只是获取资源后才再进行自我中断selfInterrupt()，将中断补上。
由于此函数是重中之重，我再用流程图总结一下：
至此，acquire()的流程终于算是告一段落了。这也就是ReentrantLock.lock()的流程，不信你去看其lock()源码吧，整个函数就是一条acquire(1)！！！
8、 release(int)
上一小节已经把acquire()说完了，这一小节就来讲讲它的反操作release()吧。此方法是独占模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果彻底释放了（即state=0）,它会唤醒等待队列里的其他线程来获取资源。该方法可以用来实现Lock.unlock方法。下面是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()来释放资源。有一点需要注意的是，它是根据tryRelease()的返回值来判断该线程是否已经完成释放掉资源了！所以自定义同步器在设计tryRelease()的时候要明确这一点！！
9、 tryRelease(int)
此方法尝试去释放指定量的资源。下面是tryRelease()的源码：
protected boolean tryRelease(int arg) { throw new UnsupportedOperationException(); }
跟tryAcquire()一样，这个方法是需要独占模式的自定义同步器去实现的。正常来说，tryRelease()都会成功的，因为这是独占模式，该线程来释放资源，那么它肯定已经拿到独占资源了，直接减掉相应量的资源即可(state-=arg)，也不需要考虑线程安全的问题。但要注意它的返回值，上面已经提到了，release()是根据tryRelease()的返回值来判断该线程是否已经完成释放掉资源了！所以自义定同步器在实现时，如果已经彻底释放资源(state=0)，要返回true，否则返回false。
10、 unparkSuccessor(Node)
此方法用于唤醒等待队列中下一个线程。下面是源码：
private void unparkSuccessor(Node node) { //这里，node一般为当前线程所在的结点。 int ws = node.waitStatus; if (ws < 0)//置零当前线程所在的结点状态，允许失败。 compareAndSetWaitStatus(node, ws, 0); Node s = node.next;//找到下一个需要唤醒的结点s if (s == null || s.waitStatus > 0) {//如果为空或已取消 s = null; for (Node t = tail; t != null && t != node; t = t.prev) if (t.waitStatus <= 0)//从这里可以看出，<=0的结点，都是还有效的结点。 s = t; } if (s != null) LockSupport.unpark(s.thread);//唤醒 }
这个函数并不复杂。一句话概括：用unpark()唤醒等待队列中最前边的那个未放弃线程，这里我们也用s来表示吧。此时，再和acquireQueued()联系起来，s被唤醒后，进入if (p == head && tryAcquire(arg))的判断（即使p!=head也没关系，它会再进入shouldParkAfterFailedAcquire()寻找一个安全点。这里既然s已经是等待队列中最前边的那个未放弃线程了，那么通过shouldParkAfterFailedAcquire()的调整，s也必然会跑到head的next结点，下一次自旋p==head就成立啦），然后s把自己设置成head标杆结点，表示自己已经获取到资源了，acquire()也返回了！！And then, DO what you WANT!
小结
release()是独占模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果彻底释放了（即state=0）,它会唤醒等待队列里的其他线程来获取资源。
11、acquireShared(int)
此方法是共享模式下线程获取共享资源的顶层入口。它会获取指定量的资源，获取成功则直接返回，获取失败则进入等待队列，直到获取到资源为止，整个过程忽略中断。下面是acquireShared()的源码.
public final void acquireShared(int arg) { if (tryAcquireShared(arg) < 0) doAcquireShared(arg); }
这里tryAcquireShared()依然需要自定义同步器去实现。但是AQS已经把其返回值的语义定义好了：负值代表获取失败；0代表获取成功，但没有剩余资源；正数表示获取成功，还有剩余资源，其他线程还可以去获取。所以这里acquireShared()的流程就是：
- tryAcquireShared()尝试获取资源，成功则直接返回；
- 失败则通过doAcquireShared()进入等待队列，直到获取到资源为止才返回。
12、 doAcquireShared(int)
此方法用于将当前线程加入等待队列尾部休息，直到其他线程释放资源唤醒自己，自己成功拿到相应量的资源后才返回。下面是doAcquireShared()的源码：
private void doAcquireShared(int arg) { final Node node = addWaiter(Node.SHARED);//加入队列尾部 boolean failed = true;//是否成功标志 try { boolean interrupted = false;//等待过程中是否被中断过的标志 for (;;) { final Node p = node.predecessor();//前驱 if (p == head) {//如果到head的下一个，因为head是拿到资源的线程，此时node被唤醒，很可能是head用完资源来唤醒自己的 int r = tryAcquireShared(arg);//尝试获取资源 if (r >= 0) {//成功 setHeadAndPropagate(node, r);//将head指向自己，还有剩余资源可以再唤醒之后的线程 p.next = null; // help GC if (interrupted)//如果等待过程中被打断过，此时将中断补上。 selfInterrupt(); failed = false; return; } } //判断状态，寻找安全点，进入waiting状态，等着被unpark()或interrupt() if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); } }
有木有觉得跟acquireQueued()很相似？对，其实流程并没有太大区别。只不过这里将补中断的selfInterrupt()放到doAcquireShared()里了，而独占模式是放到acquireQueued()之外，其实都一样，不知道Doug Lea是怎么想的。
跟独占模式比，还有一点需要注意的是，这里只有线程是head.next时（“老二”），才会去尝试获取资源，有剩余的话还会唤醒之后的队友。那么问题就来了，假如老大用完后释放了5个资源，而老二需要6个，老三需要1个，老四需要2个。老大先唤醒老二，老二一看资源不够，他是把资源让给老三呢，还是不让？答案是否定的！老二会继续park()等待其他线程释放资源，也更不会去唤醒老三和老四了。独占模式，同一时刻只有一个线程去执行，这样做未尝不可；但共享模式下，多个线程是可以同时执行的，现在因为老二的资源需求量大，而把后面量小的老三和老四也都卡住了。当然，这并不是问题，只是AQS保证严格按照入队顺序唤醒罢了（保证公平，但降低了并发）。
13、setHeadAndPropagate(Node, int)
private void setHeadAndPropagate(Node node, int propagate) { Node h = head; setHead(node);//head指向自己 //如果还有剩余量，继续唤醒下一个邻居线程 if (propagate > 0 || h == null || h.waitStatus < 0) { Node s = node.next; if (s == null || s.isShared()) doReleaseShared(); } }
此方法在setHead()的基础上多了一步，就是自己苏醒的同时，如果条件符合（比如还有剩余资源），还会去唤醒后继结点，毕竟是共享模式！
doReleaseShared()我们留着下一小节的releaseShared()里来讲。
小结
至此，acquireShared()也要告一段落了。让我们再梳理一下它的流程：
- tryAcquireShared()尝试获取资源，成功则直接返回；
- 失败则通过doAcquireShared()进入等待队列park()，直到被unpark()/interrupt()并成功获取到资源才返回。整个等待过程也是忽略中断的。
其实跟acquire()的流程大同小异，只不过多了个自己拿到资源后，还会去唤醒后继队友的操作（这才是共享嘛）。
14、releaseShared()
上一小节已经把acquireShared()说完了，这一小节就来讲讲它的反操作releaseShared()吧。此方法是共享模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果成功释放且允许唤醒等待线程，它会唤醒等待队列里的其他线程来获取资源。下面是releaseShared()的源码：
public final boolean releaseShared(int arg) { if (tryReleaseShared(arg)) {//尝试释放资源 doReleaseShared();//唤醒后继结点 return true; } return false; }
此方法的流程也比较简单，一句话：释放掉资源后，唤醒后继。跟独占模式下的release()相似，但有一点稍微需要注意：独占模式下的tryRelease()在完全释放掉资源（state=0）后，才会返回true去唤醒其他线程，这主要是基于独占下可重入的考量；而共享模式下的releaseShared()则没有这种要求，共享模式实质就是控制一定量的线程并发执行，那么拥有资源的线程在释放掉部分资源时就可以唤醒后继等待结点。例如，资源总量是13，A（5）和B（7）分别获取到资源并发运行，C（4）来时只剩1个资源就需要等待。A在运行过程中释放掉2个资源量，然后tryReleaseShared(2)返回true唤醒C，C一看只有3个仍不够继续等待；随后B又释放2个，tryReleaseShared(2)返回true唤醒C，C一看有5个够自己用了，然后C就可以跟A和B一起运行。而ReentrantReadWriteLock读锁的tryReleaseShared()只有在完全释放掉资源（state=0）才返回true，所以自定义同步器可以根据需要决定tryReleaseShared()的返回值。
15、doReleaseShared()
此方法主要用于唤醒后继。下面是它的源码：
private void doReleaseShared() { for (;;) { Node h = head; if (h != null && h != tail) { int ws = h.waitStatus; if (ws == Node.SIGNAL) { if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0)) continue; unparkSuccessor(h);//唤醒后继 } else if (ws == 0 && !compareAndSetWaitStatus(h, 0, Node.PROPAGATE)) continue; } if (h == head)// head发生变化 break; } }
独占式 VS 共享式
从概念上来说独占式期望的是只有一个线程或者说竞争者获取同步状态，而共享式期望的是有多个线程或者竞争者能够获取同步状态。然而在实现上能否获取独占式同步状态和能否获取共享式同步状态是开放给子类自己去实现的。我们同样可以通过重写acquire(int arg)方法实现让多个线程获取独占式同步状态只是并没有这么做而已。那么他们的区别在哪？他们获取同步状态方式相同，获取失败进入阻塞队列同样相同。他们唯一的不同点在于共享式释放同步状态后，==唤醒同步队列中节点中的线程的阻塞，让唤醒线程去竞争同步状态这个动作具有具有传播性==
-
独占式在释放同步状态时，会找到从head头部后置节点中线程，使其从阻塞中释放，并在自旋中重新竞争同步状态，如果获取成功则出队。
-
共享式在释放同步状态时，会找到从head头部后置节点中线程，使其从阻塞中释放，并在自旋中重新竞争同步状态，如果获取成功则出队。同时会判断新head节点后置节点是否是共享节点，如果是则会再次释放同步状态。由于之前操作已经存在出队，此时head节点已经改变。依此重复上面操作：会找到从head头部后置节点中线程，使其从阻塞中释放，并在自旋中重新竞争同步状态，如果获取成功则出队，直至某一个释放的节点尝试获取同步状态失败或者同步队列已经不存在等待的节点结束。
AQS应用
如上所述，AQS管理一个关于状态信息的单一整数，该整数可以表现任何状态。比如， Semaphore 用它来表现剩余的许可数，ReentrantLock 用它来表现拥有它的线程已经请求了多少次锁；FutureTask 用它来表现任务的状态(尚未开始、运行、完成和取消)。
下面以 CountDownLatch 举例说明基于AQS实现同步器, CountDownLatch 用同步状态持有当前计数，countDown方法调用 release从而导致计数器递减；当计数器为0时，解除所有线程的等待；await调用acquire，如果计数器为0，acquire 会立即返回，否则阻塞。通常用于某任务需要等待其他任务都完成后才能继续执行的情景。源码如下:
public class CountDownLatch { /** * 基于AQS的内部Sync * 使用AQS的state来表示计数count. */ private static final class Sync extends AbstractQueuedSynchronizer { private static final long serialVersionUID = 4982264981922014374L; Sync(int count) { // 使用AQS的getState()方法设置状态 setState(count); } int getCount() { // 使用AQS的getState()方法获取状态 return getState(); } // 覆盖在共享模式下尝试获取锁 protected int tryAcquireShared(int acquires) { // 这里用状态state是否为0来表示是否成功，为0的时候可以获取到返回1，否则不可以返回-1 return (getState() == 0) ? 1 : -1; } // 覆盖在共享模式下尝试释放锁 protected boolean tryReleaseShared(int releases) { // 在for循环中Decrement count直至成功; // 当状态值即count为0的时候，返回false表示 signal when transition to zero for (;;) { int c = getState(); if (c == 0) return false; int nextc = c-1; if (compareAndSetState(c, nextc)) return nextc == 0; } } } private final Sync sync; // 使用给定计数值构造CountDownLatch public CountDownLatch(int count) { if (count < 0) throw new IllegalArgumentException("count < 0"); this.sync = new Sync(count); } // 让当前线程阻塞直到计数count变为0，或者线程被中断 public void await() throws InterruptedException { sync.acquireSharedInterruptibly(1); } // 阻塞当前线程，除非count变为0或者等待了timeout的时间。当count变为0时，返回true public boolean await(long timeout, TimeUnit unit) throws InterruptedException { return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout)); } // count递减 public void countDown() { sync.releaseShared(1); } // 获取当前count值 public long getCount() { return sync.getCount(); } public String toString() { return super.toString() + "[Count = " + sync.getCount() + "]"; } }
再以AQS源码里的Mutex（互斥锁）为例，讲一下AQS的简单应用。
Mutex是一个不可重入的互斥锁实现。锁资源（AQS里的state）只有两种状态：0表示未锁定，1表示锁定。下边是Mutex的核心源码：
class Mutex implements Lock, java.io.Serializable { // 自定义同步器 private static class Sync extends AbstractQueuedSynchronizer { // 判断是否锁定状态 protected boolean isHeldExclusively() { return getState() == 1; } // 尝试获取资源，立即返回。成功则返回true，否则false。 public boolean tryAcquire(int acquires) { assert acquires == 1; // 这里限定只能为1个量 if (compareAndSetState(0, 1)) {//state为0才设置为1，不可重入！ setExclusiveOwnerThread(Thread.currentThread());//设置为当前线程独占资源 return true; } return false; } // 尝试释放资源，立即返回。成功则为true，否则false。 protected boolean tryRelease(int releases) { assert releases == 1; // 限定为1个量 if (getState() == 0)//既然来释放，那肯定就是已占有状态了。只是为了保险，多层判断！ throw new IllegalMonitorStateException(); setExclusiveOwnerThread(null); setState(0);//释放资源，放弃占有状态 return true; } } // 真正同步类的实现都依赖继承于AQS的自定义同步器！ private final Sync sync = new Sync(); //lock<-->acquire。两者语义一样：获取资源，即便等待，直到成功才返回。 public void lock() { sync.acquire(1); } //tryLock<-->tryAcquire。两者语义一样：尝试获取资源，要求立即返回。成功则为true，失败则为false。 public boolean tryLock() { return sync.tryAcquire(1); } //unlock<-->release。两者语文一样：释放资源。 public void unlock() { sync.release(1); } //锁是否占有状态 public boolean isLocked() { return sync.isHeldExclusively(); } }
同步类在实现时一般都将自定义同步器（sync）定义为内部类，供自己使用；而同步类自己（Mutex）则实现某个接口，对外服务。当然，接口的实现要直接依赖sync，它们在语义上也存在某种对应关系！！而sync只用实现资源state的获取-释放方式tryAcquire-tryRelelase，至于线程的排队、等待、唤醒等，上层的AQS都已经实现好了，我们不用关心。
Semaphore(信号量)-允许多个线程同时访问
Semaphore是一个计数信号量。
从概念上将，Semaphore包含一组许可证。
如果有需要的话，每个acquire()方法都会阻塞，直到获取一个可用的许可证。
每个release()方法都会释放持有许可证的线程，并且归还Semaphore一个可用的许可证。
然而，实际上并没有真实的许可证对象供线程使用，Semaphore只是对可用的数量进行管理维护。
synchronized 和 ReentrantLock 都是一次只允许一个线程访问某个资源，Semaphore(信号量)可以指定多个线程同时访问某个资源。具体解释和应用可参见 深入浅出java Semapho
除了Mutex，ReentrantLock/CountDownLatch/Semphore这些同步类的实现方式都差不多，不同的地方就在获取-释放资源的方式tryAcquire-tryRelelase。
参考：https://www.cnblogs.com/waterystone/p/4920797.html
https://www.jianshu.com/p/92568acbe5e6
