AQS（AbstractQuenedSynchronizer 抽象队列同步器） 是一个用来构建锁和同步器的框架，使用 AQS能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的ReentrantLock，Semaphore，其他的诸如 ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于 AQS的。AQS是一种提供了原子式管理同步状态、阻塞和唤醒线程功能以及队列模型的简单框架。当然，我们自己也能利用 AQS非常轻松容易地构造出符合我们自己需求的同步器。AQS 框架如下：上图中有颜色的为Method，无颜色的为Attribution。
总的来说，AQS框架共分为五层，自上而下由浅入深，从 AQS对外暴露的 API到底层基础数据。当有自定义同步器接入时，只需重写第一层所需要的部分方法即可，不需要关注底层具体的实现流程。当自定义同步器进行加锁或者解锁操作时，先经过第一层的API进入AQS内部方法，然后经过第二层进行锁的获取，接着对于获取锁失败的流程，进入第三层和第四层的等待队列处理，而这些处理方式均依赖于第五层的基础数据提供层。
一、AQS 核心思想
AQS核心思想：如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS是用 CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。
CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列(虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系)。AQS是将每条请求共享资源的线程封装成一个 CLH锁队列的一个结点(Node)来实现锁的分配。CLH锁是一个自旋锁。能确保无饥饿性。提供先来先服务的公平性。
AQS使用一个 int成员变量来表示同步状态，通过内置的 FIFO队列来完成获取资源线程的排队工作。AQS使用 CAS对该同步状态进行原子操作实现对其值的修改。
private volatile int state;//共享变量，使用volatile修饰保证线程可见性
状态信息通过 procted类型的 getState，setState，compareAndSetState进行操作
1 //返回同步状态的当前值
2 protected final int getState() {
3 return state;
4 }
5 // 设置同步状态的值
6 protected final void setState(int newState) {
7 state = newState;
8 }
9 //原子地(CAS操作)将同步状态值设置为给定值update如果当前同步状态的值等于expect(期望值)
10 protected final boolean compareAndSetState(int expect, int update) {
11 return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
12 }
二、AQS 对资源的共享方式
AQS定义两种资源共享方式：
【1】Exclusive(独占)：只有一个线程能执行，如 ReentrantLock。又可分为公平锁和非公平锁：
● **公平锁：**按照线程在队列中的排队顺序，先到者先拿到锁；
● **非公平锁：**当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的；
【2】Share(共享)：多个线程可同时执行，如Semaphore/CountDownLatch。
ReentrantReadWriteLock 可以看成是组合式，因为 ReentrantReadWriteLock也就是读写锁允许多个线程对某资源进行读。
不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护(如获取资源失败入队/唤醒出队等)，AQS已经在上层已经帮我们实现好了。
三、AQS 底层使用了模板模式
AQS核心思想是，如果被请求的共享资源空闲，那么就将当前请求资源的线程设置为有效的工作线程，将共享资源设置为锁定状态；如果共享资源被占用，就需要一定的阻塞等待唤醒机制来保证锁分配。这个机制主要用的是 CLH队列的变体实现的，将暂时获取不到锁的线程加入到队列中。
CLH：Craig、Landin and Hagersten队列，是单向链表，AQS中的队列是 CLH变体的虚拟双向队列（FIFO），AQS是通过将每条请求共享资源的线程封装成一个节点来实现锁的分配。主要原理图如下：
AQS使用一个 Volatile的 int类型的成员变量来表示同步状态，通过内置的 FIFO队列来完成资源获取的排队工作，通过 CAS完成对 State值的修改。
同步器的设计基于模板模式【链接】，如果需要自定义同步器一般的方式是：使用者继承 AbstractQueuedSynchronizer 并重写指定的方法。(这些重写方法很简单，无非是对于共享资源 state的获取和释放) 将 AQS组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。自定义同步器时需要重写下面几个 AQS提供的模板方法：
1 isHeldExclusively()//该线程是否正在独占资源。只有用到condition才需要去实现它。
2 tryAcquire(int)//独占方式。尝试获取资源，成功则返回true，失败则返回false。
3 tryRelease(int)//独占方式。尝试释放资源，成功则返回true，失败则返回false。
4 tryAcquireShared(int)//共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
5 tryReleaseShared(int)//共享方式。尝试释放资源，成功则返回true，失败则返回false。
默认情况下，每个方法都抛出 UnsupportedOperationException。 这些方法的实现必须是内部线程安全的，并且通常应该简短而不是阻塞。AQS类中的其他方法都是final ，所以无法被其他类使用，只有这几个方法可以被其他类使用。
以 ReentrantLock为例，state初始化为0，表示未锁定状态。A线程 lock()时，会调用 tryAcquire()独占该锁并将 state+1。此后，其他线程再 tryAcquire()时就会失败，直到 A线程 unlock()到 state=0(即释放锁)为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的(state会累加)，这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证 state是能回到零态的。
四、AQS 数据结构
AbstractQueuedSynchronizer 类底层的数据结构是使用 CLH(Craig,Landin,and Hagersten) 队列是一个虚拟的双向队列。其中Sync queue，即同步队列，是双向链表，包括 head结点和 tail结点，head结点主要用作后续的调度。而 Condition queue不是必须的，其是一个单向链表，只有当使用 Condition时，才会存在此单向链表。并且可能会有多个 Condition queue。
五、AQS 源码分析
**类的继承关系：**AQS继承自 AbstractOwnableSynchronizer抽象类，并且实现了 Serializable接口，可以进行序列化。
public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable
其中 AbstractOwnableSynchronizer抽象类的源码如下：
1 public abstract class AbstractOwnableSynchronizer implements java.io.Serializable {
2
3 // 版本序列号
4 private static final long serialVersionUID = 3737899427754241961L;
5 // 构造方法
6 protected AbstractOwnableSynchronizer() { }
7 // 独占模式下的线程
8 private transient Thread exclusiveOwnerThread;
9
10 // 设置独占线程
11 protected final void setExclusiveOwnerThread(Thread thread) {
12 exclusiveOwnerThread = thread;
13 }
14
15 // 获取独占线程
16 protected final Thread getExclusiveOwnerThread() {
17 return exclusiveOwnerThread;
18 }
19 }
AbstractOwnableSynchronizer抽象类中，可以设置独占资源线程和获取独占资源线程。分别为 setExclusiveOwnerThread与getExclusiveOwnerThread方法，这两个方法会被子类调用。AbstractQueuedSynchronizer类有两个内部类，分别为 Node类与 ConditionObject类。下面分别做介绍。
六、类的内部类 - Node类
先来看下AQS中最基本的数据结构Node，Node即为上面 CLH变体队列中的节点。
解释一下几个方法和属性值的含义：
| 方法和属性值 | 含义 |
|---|---|
| waitStatus | 当前节点在队列中的状态 |
| thread | 表示处于该节点的线程 |
| prev | 前驱指针 |
| predecessor | 返回前驱节点，没有的话抛出npe |
| nextWaiter | 指向下一个处于CONDITION状态的节点（由于本篇文章不讲述Condition Queue队列，这个指针不多介绍） |
| next | 后继指针 |
线程两种锁的模式：
| 模式 | 含义 |
|---|---|
| SHARED | 表示线程以共享的模式等待锁 |
| EXCLUSIVE | 表示线程正在以独占的方式等待锁 |
waitStatus有下面几个枚举值：每个节点包含了一个 Thread类型的引用，并且每个节点都存在一个状态，具体状态如下：
| 枚举 | 含义 |
|---|---|
| 0 | 当一个Node被初始化的时候的默认值 |
| CANCELLED | 为1，表示线程获取锁的请求已经取消了 |
| CONDITION | 为-2，表示节点在等待队列中，节点线程等待唤醒 |
| PROPAGATE | 为-3，当前线程处在SHARED情况下，该字段才会使用 |
| SIGNAL | 为-1，表示线程已经准备好了，就等资源释放了 |
1 static final class Node {
2 // 模式，分为共享与独占
3 // 共享模式
4 static final Node SHARED = new Node();
5 // 独占模式
6 static final Node EXCLUSIVE = null;
7 // 结点状态
8 // CANCELLED，值为1，表示当前的线程被取消
9 // SIGNAL，值为-1，表示当前节点的后继节点包含的线程需要运行，也就是unpark
10 // CONDITION，值为-2，表示当前节点在等待condition，也就是在condition队列中
11 // PROPAGATE，值为-3，表示当前场景下后续的acquireShared能够得以执行
12 // 值为0，表示当前节点在sync队列中，等待着获取锁
13 static final int CANCELLED = 1;
14 static final int SIGNAL = -1;
15 static final int CONDITION = -2;
16 static final int PROPAGATE = -3;
17
18 // 结点状态
19 volatile int waitStatus;
20 // 前驱结点
21 volatile Node prev;
22 // 后继结点
23 volatile Node next;
24 // 结点所对应的线程
25 volatile Thread thread;
26 // 下一个等待者
27 Node nextWaiter;
28
29 // 结点是否在共享模式下等待
30 final boolean isShared() {
31 return nextWaiter == SHARED;
32 }
33
34 // 获取前驱结点，若前驱结点为空，抛出异常
35 final Node predecessor() throws NullPointerException {
36 // 保存前驱结点
37 Node p = prev;
38 if (p == null) // 前驱结点为空，抛出异常
39 throw new NullPointerException();
40 else // 前驱结点不为空，返回
41 return p;
42 }
43
44 // 无参构造方法
45 Node() { // Used to establish initial head or SHARED marker
46 }
47
48 // 构造方法
49 Node(Thread thread, Node mode) { // Used by addWaiter
50 this.nextWaiter = mode;
51 this.thread = thread;
52 }
53
54 // 构造方法
55 Node(Thread thread, int waitStatus) { // Used by Condition
56 this.waitStatus = waitStatus;
57 this.thread = thread;
58 }
59 }
七、类的内部类 - ConditionObject类
// 内部类
public class ConditionObject implements Condition, java.io.Serializable {
// 版本号
private static final long serialVersionUID = 1173984872572414699L;
// condition队列的头结点
private transient Node firstWaiter;
// condition队列的尾结点
private transient Node lastWaiter;
// 构造方法
public ConditionObject() { }
// 添加新的 waiter到 wait队列
private Node addConditionWaiter() {
// 保存尾结点
Node t = lastWaiter;
// If lastWaiter is cancelled, clean out.
if (t != null && t.waitStatus != Node.CONDITION) { // 尾结点不为空，并且尾结点的状态不为CONDITION
// 清除状态为CONDITION的结点
unlinkCancelledWaiters();
// 将最后一个结点重新赋值给t
t = lastWaiter;
}
// 新建一个结点
Node node = new Node(Thread.currentThread(), Node.CONDITION);
if (t == null) // 尾结点为空
// 设置condition队列的头结点
firstWaiter = node;
else // 尾结点不为空
// 设置为节点的nextWaiter域为node结点
t.nextWaiter = node;
// 更新condition队列的尾结点
lastWaiter = node;
return node;
}
/**
* 移除并传输节点，直到命中未取消的节点或空的。从signal中分离出来部分是为了鼓励编译器在没有服务员的情况下。
*@param first（非空）条件队列的第一个节点
*/
private void doSignal(Node first) {
// 循环
do {
if ( (firstWaiter = first.nextWaiter) == null) // 该节点的nextWaiter为空
// 设置尾结点为空
lastWaiter = null;
// 设置first结点的nextWaiter域
first.nextWaiter = null;
} while (!transferForSignal(first) &&
(first = firstWaiter) != null); // 将结点从condition队列转移到sync队列失败并且condition队列中的头结点不为空，一直循环
}
/**
* 移除并传输所有节点。
* @param first (non-null) 第一个节点
*/
private void doSignalAll(Node first) {
// condition队列的头结点尾结点都设置为空
lastWaiter = firstWaiter = null;
// 循环
do {
// 获取first结点的nextWaiter域结点
Node next = first.nextWaiter;
// 设置first结点的nextWaiter域为空
first.nextWaiter = null;
// 将first结点从condition队列转移到sync队列
transferForSignal(first);
// 重新设置first
first = next;
} while (first != null);
}
// 从condition队列中清除状态为CANCEL的结点
private void unlinkCancelledWaiters() {
// 保存condition队列头结点
Node t = firstWaiter;
Node trail = null;
while (t != null) { // t不为空
// 下一个结点
Node next = t.nextWaiter;
if (t.waitStatus != Node.CONDITION) { // t结点的状态不为CONDTION状态
// 设置t节点的额nextWaiter域为空
t.nextWaiter = null;
if (trail == null) // trail为空
// 重新设置condition队列的头结点
firstWaiter = next;
else // trail不为空
// 设置trail结点的nextWaiter域为next结点
trail.nextWaiter = next;
if (next == null) // next结点为空
// 设置condition队列的尾结点
lastWaiter = trail;
}
else // t结点的状态为CONDTION状态
// 设置trail结点
trail = t;
// 设置t结点
t = next;
}
}
// 唤醒一个等待线程。如果所有的线程都在等待此条件，则选择其中的一个唤醒。在从 await 返回之前，该线程必须重新获取锁。
public final void signal() {
if (!isHeldExclusively()) // 不被当前线程独占，抛出异常
throw new IllegalMonitorStateException();
// 保存condition队列头结点
Node first = firstWaiter;
if (first != null) // 头结点不为空
// 唤醒一个等待线程
doSignal(first);
}
// 唤醒所有等待线程。如果所有的线程都在等待此条件，则唤醒所有线程。在从 await 返回之前，每个线程都必须重新获取锁。
public final void signalAll() {
if (!isHeldExclusively()) // 不被当前线程独占，抛出异常
throw new IllegalMonitorStateException();
// 保存condition队列头结点
Node first = firstWaiter;
if (first != null) // 头结点不为空
// 唤醒所有等待线程
doSignalAll(first);
}
// 等待，当前线程在接到信号之前一直处于等待状态，不响应中断
public final void awaitUninterruptibly() {
// 添加一个结点到等待队列
Node node = addConditionWaiter();
// 获取释放的状态
int savedState = fullyRelease(node);
boolean interrupted = false;
while (!isOnSyncQueue(node)) { //
// 阻塞当前线程
LockSupport.park(this);
if (Thread.interrupted()) // 当前线程被中断
// 设置interrupted状态
interrupted = true;
}
if (acquireQueued(node, savedState) || interrupted) //
selfInterrupt();
}
/** Mode meaning to reinterrupt on exit from wait */
private static final int REINTERRUPT = 1;
/** Mode meaning to throw InterruptedException on exit from wait */
private static final int THROW_IE = -1;
/**
* 检查是否有中断，如果中断则返回THROW-IE 在发出信号之前，如果在发出信号后重新中断，或者如果没有中断，则为0。
*/
private int checkInterruptWhileWaiting(Node node) {
return Thread.interrupted() ?
(transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT) :
0;
}
/**
* 引发InterruptedException，重新中断当前线程，或什么都不做，取决于模式。
*/
private void reportInterruptAfterWait(int interruptMode)
throws InterruptedException {
if (interruptMode == THROW_IE)
throw new InterruptedException();
else if (interruptMode == REINTERRUPT)
selfInterrupt();
}
// 等待，当前线程在接到信号或被中断之前一直处于等待状态
public final void await() throws InterruptedException {
if (Thread.interrupted()) // 当前线程被中断，抛出异常
throw new InterruptedException();
// 在wait队列上添加一个结点
Node node = addConditionWaiter();
//
int savedState = fullyRelease(node);
int interruptMode = 0;
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);
}
// 等待，当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态
public final long awaitNanos(long nanosTimeout)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
Node node = addConditionWaiter();
int savedState = fullyRelease(node);
final long deadline = System.nanoTime() + nanosTimeout;
int interruptMode = 0;
while (!isOnSyncQueue(node)) {
if (nanosTimeout <= 0L) {
transferAfterCancelledWait(node);
break;
}
if (nanosTimeout >= spinForTimeoutThreshold)
LockSupport.parkNanos(this, nanosTimeout);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
nanosTimeout = deadline - System.nanoTime();
}
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null)
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
return deadline - System.nanoTime();
}
// 等待，当前线程在接到信号、被中断或到达指定最后期限之前一直处于等待状态
public final boolean awaitUntil(Date deadline)
throws InterruptedException {
long abstime = deadline.getTime();
if (Thread.interrupted())
throw new InterruptedException();
Node node = addConditionWaiter();
int savedState = fullyRelease(node);
boolean timedout = false;
int interruptMode = 0;
while (!isOnSyncQueue(node)) {
if (System.currentTimeMillis() > abstime) {
timedout = transferAfterCancelledWait(node);
break;
}
LockSupport.parkUntil(this, abstime);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null)
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
return !timedout;
}
// 等待，当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。此方法在行为上等效于: awaitNanos(unit.toNanos(time)) > 0
public final boolean await(long time, TimeUnit unit)
throws InterruptedException {
long nanosTimeout = unit.toNanos(time);
if (Thread.interrupted())
throw new InterruptedException();
Node node = addConditionWaiter();
int savedState = fullyRelease(node);
final long deadline = System.nanoTime() + nanosTimeout;
boolean timedout = false;
int interruptMode = 0;
while (!isOnSyncQueue(node)) {
if (nanosTimeout <= 0L) {
timedout = transferAfterCancelledWait(node);
break;
}
if (nanosTimeout >= spinForTimeoutThreshold)
LockSupport.parkNanos(this, nanosTimeout);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
nanosTimeout = deadline - System.nanoTime();
}
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null)
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
return !timedout;
}
/**
* 如果此条件是由给定的同步对象创建的，则返回true
*/
final boolean isOwnedBy(AbstractQueuedSynchronizer sync) {
return sync == AbstractQueuedSynchronizer.this;
}
// 查询是否有正在等待此条件的任何线程
protected final boolean hasWaiters() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
for (Node w = firstWaiter; w != null; w = w.nextWaiter) {
if (w.waitStatus == Node.CONDITION)
return true;
}
return false;
}
// 返回正在等待此条件的线程数估计值
protected final int getWaitQueueLength() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
int n = 0;
for (Node w = firstWaiter; w != null; w = w.nextWaiter) {
if (w.waitStatus == Node.CONDITION)
++n;
}
return n;
}
// 返回包含那些可能正在等待此条件的线程集合
protected final Collection<Thread> getWaitingThreads() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
ArrayList<Thread> list = new ArrayList<Thread>();
for (Node w = firstWaiter; w != null; w = w.nextWaiter) {
if (w.waitStatus == Node.CONDITION) {
Thread t = w.thread;
if (t != null)
list.add(t);
}
}
return list;
}
}
此类实现了 Condition接口，Condition接口定义了条件操作规范，具体如下：Condition接口中定义了await、signal方法，用来等待条件、释放条件。
1 public interface Condition {
2
3 // 等待，当前线程在接到信号或被中断之前一直处于等待状态
4 void await() throws InterruptedException;
5
6 // 等待，当前线程在接到信号之前一直处于等待状态，不响应中断
7 void awaitUninterruptibly();
8
9 //等待，当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态
10 long awaitNanos(long nanosTimeout) throws InterruptedException;
11
12 // 等待，当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。此方法在行为上等效于: awaitNanos(unit.toNanos(time)) > 0
13 boolean await(long time, TimeUnit unit) throws InterruptedException;
14
15 // 等待，当前线程在接到信号、被中断或到达指定最后期限之前一直处于等待状态
16 boolean awaitUntil(Date deadline) throws InterruptedException;
17
18 // 唤醒一个等待线程。如果所有的线程都在等待此条件，则选择其中的一个唤醒。在从 await 返回之前，该线程必须重新获取锁。
19 void signal();
20
21 // 唤醒所有等待线程。如果所有的线程都在等待此条件，则唤醒所有线程。在从 await 返回之前，每个线程都必须重新获取锁。
22 void signalAll();
23 }
八、AQS 类源码
类的属性：包含了头结点head，尾结点tail，状态state、自旋时间spinForTimeoutThreshold，还有 AQS抽象的属性在内存中的偏移地址，通过该偏移地址，可以获取和设置该属性的值，同时还包括一个静态初始化块，用于加载内存偏移地址。
1 public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer
2 implements java.io.Serializable {
3 // 版本号
4 private static final long serialVersionUID = 7373984972572414691L;
5 // 头结点
6 private transient volatile Node head;
7 // 尾结点
8 private transient volatile Node tail;
9 // 状态
10 private volatile int state;
11 // 自旋时间
12 static final long spinForTimeoutThreshold = 1000L;
13
14 // Unsafe类实例
15 private static final Unsafe unsafe = Unsafe.getUnsafe();
16 // state内存偏移地址
17 private static final long stateOffset;
18 // head内存偏移地址
19 private static final long headOffset;
20 // state内存偏移地址
21 private static final long tailOffset;
22 // tail内存偏移地址
23 private static final long waitStatusOffset;
24 // next内存偏移地址
25 private static final long nextOffset;
26 // 静态初始化块
27 static {
28 try {
29 stateOffset = unsafe.objectFieldOffset
30 (AbstractQueuedSynchronizer.class.getDeclaredField("state"));
31 headOffset = unsafe.objectFieldOffset
32 (AbstractQueuedSynchronizer.class.getDeclaredField("head"));
33 tailOffset = unsafe.objectFieldOffset
34 (AbstractQueuedSynchronizer.class.getDeclaredField("tail"));
35 waitStatusOffset = unsafe.objectFieldOffset
36 (Node.class.getDeclaredField("waitStatus"));
37 nextOffset = unsafe.objectFieldOffset
38 (Node.class.getDeclaredField("next"));
39
40 } catch (Exception ex) { throw new Error(ex); }
41 }
42 }
**类的构造方法：**此类构造方法为空抽象构造方法，供子类调用。
1 protected AbstractQueuedSynchronizer() { }
类的核心方法acquire：该方法以独占模式获取(资源)，忽略中断，即线程在 acquire过程中，中断此线程是无效的。源码如下：
1 public final void acquire(int arg) {
2 if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
3 selfInterrupt();
4 }
由上述源码可以知道，当一个线程调用 acquire时，调用方法流程如下：
【1】首先调用 tryAcquire方法，调用此方法的线程会试图在独占模式下获取对象状态。此方法应该查询是否允许它在独占模式下获取对象状态，如果允许，则获取它。在 AbstractQueuedSynchronizer源码中默认会抛出一个异常，即需要子类去重写此方法完成自己的逻辑。之后会进行分析。
【2】若 tryAcquire失败，则调用 addWaiter方法，addWaiter方法完成的功能是将调用此方法的线程封装成为一个结点并放入Sync queue。
【3】调用 acquireQueued方法，此方法完成的功能是Sync queue中的结点不断尝试获取资源，若成功，则返回true，否则，返回false。
【4】由于 tryAcquire默认实现是抛出异常，所以此时，不进行分析，之后会结合一个例子进行分析。
首先分析 addWaiter方法：
1 // 添加等待者
2 private Node addWaiter(Node mode) {
3 // 新生成一个结点，默认为独占模式
4 Node node = new Node(Thread.currentThread(), mode);
5 // Try the fast path of enq; backup to full enq on failure
6 // 保存尾结点
7 Node pred = tail;
8 if (pred != null) { // 尾结点不为空，即已经被初始化
9 // 将node结点的prev域连接到尾结点
10 node.prev = pred;
11 if (compareAndSetTail(pred, node)) { // 比较pred是否为尾结点，是则将尾结点设置为node
12 // 设置尾结点的next域为node
13 pred.next = node;
14 return node; // 返回新生成的结点
15 }
16 }
17 enq(node); // 尾结点为空(即还没有被初始化过)，或者是compareAndSetTail操作失败，则入队列
18 return node;
19 }
addWaiter 方法使用快速添加的方式往 sync queue尾部添加结点，如果 sync queue队列还没有初始化，则会使用 enq插入队列中，enq方法源码如下：
1 private Node enq(final Node node) {
2 for (;;) { // 无限循环，确保结点能够成功入队列
3 // 保存尾结点
4 Node t = tail;
5 if (t == null) { // 尾结点为空，即还没被初始化
6 if (compareAndSetHead(new Node())) // 头结点为空，并设置头结点为新生成的结点
7 tail = head; // 头结点与尾结点都指向同一个新生结点
8 } else { // 尾结点不为空，即已经被初始化过
9 // 将node结点的prev域连接到尾结点
10 node.prev = t;
11 if (compareAndSetTail(t, node)) { // 比较结点t是否为尾结点，若是则将尾结点设置为node
12 // 设置尾结点的next域为node
13 t.next = node;
14 return t; // 返回尾结点
15 }
16 }
17 }
18 }
enq方法会使用无限循环来确保节点的成功插入。现在，分析 acquireQueue方法。其源码如下：
1 // sync队列中的结点在独占且忽略中断的模式下获取(资源)
2 final boolean acquireQueued(final Node node, int arg) {
3 // 标志
4 boolean failed = true;
5 try {
6 // 中断标志
7 boolean interrupted = false;
8 for (;;) { // 无限循环
9 // 获取node节点的前驱结点
10 final Node p = node.predecessor();
11 if (p == head && tryAcquire(arg)) { // 前驱为头结点并且成功获得锁
12 setHead(node); // 设置头结点
13 p.next = null; // help GC
14 failed = false; // 设置标志
15 return interrupted;
16 }
17 if (shouldParkAfterFailedAcquire(p, node) &&
18 parkAndCheckInterrupt())
19 interrupted = true;
20 }
21 } finally {
22 if (failed)
23 cancelAcquire(node);
24 }
25 }
首先获取当前节点的前驱节点，如果前驱节点是头结点并且能够获取(资源)，代表该当前节点能够占有锁，设置头结点为当前节点，返回。否则，调用 shouldParkAfterFailedAcquire 和 parkAndCheckInterrupt 方法，首先，我们看shouldParkAfterFailedAcquire方法，代码如下：
1 // 当获取(资源)失败后，检查并且更新结点状态
2 private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
3 // 获取前驱结点的状态
4 int ws = pred.waitStatus;
5 if (ws == Node.SIGNAL) // 状态为SIGNAL，为-1
6 /*
7 * This node has already set status asking a release
8 * to signal it, so it can safely park.
9 */
10 // 可以进行park操作
11 return true;
12 if (ws > 0) { // 表示状态为CANCELLED，为1
13 /*
14 * Predecessor was cancelled. Skip over predecessors and
15 * indicate retry.
16 */
17 do {
18 node.prev = pred = pred.prev;
19 } while (pred.waitStatus > 0); // 找到pred结点前面最近的一个状态不为CANCELLED的结点
20 // 赋值pred结点的next域
21 pred.next = node;
22 } else { // 为PROPAGATE -3 或者是0 表示无状态,(为CONDITION -2时，表示此节点在condition queue中)
23 /*
24 * waitStatus must be 0 or PROPAGATE. Indicate that we
25 * need a signal, but don't park yet. Caller will need to
26 * retry to make sure it cannot acquire before parking.
27 */
28 // 比较并设置前驱结点的状态为SIGNAL
29 compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
30 }
31 // 不能进行park操作
32 return false;
33 }
只有当该节点的前驱结点的状态为 SIGNAL时，才可以对该结点所封装的线程进行 park操作。否则，将不能进行 park操作。再看parkAndCheckInterrupt方法，源码如下：
1 // 进行park操作并且返回该线程是否被中断
2 private final boolean parkAndCheckInterrupt() {
3 // 在许可可用之前禁用当前线程，并且设置了blocker
4 LockSupport.park(this);
5 return Thread.interrupted(); // 当前线程是否已被中断，并清除中断标记位
6 }
parkAndCheckInterrupt方法里的逻辑是首先执行 park操作，即禁用当前线程，然后返回该线程是否已经被中断。再看 final块中的cancelAcquire方法，其源码如下：
// 取消继续获取(资源)
private void cancelAcquire(Node node) {
// Ignore if node doesn't exist
// node为空，返回
if (node == null)
return;
// 设置node结点的thread为空
node.thread = null;
// Skip cancelled predecessors
// 保存node的前驱结点
Node pred = node.prev;
while (pred.waitStatus > 0) // 找到node前驱结点中第一个状态小于0的结点，即不为CANCELLED状态的结点
node.prev = pred = pred.prev;
// predNext is the apparent node to unsplice. CASes below will
// fail if not, in which case, we lost race vs another cancel
// or signal, so no further action is necessary.
// 获取pred结点的下一个结点
Node predNext = pred.next;
// Can use unconditional write instead of CAS here.
// After this atomic step, other Nodes can skip past us.
// Before, we are free of interference from other threads.
// 设置node结点的状态为CANCELLED
node.waitStatus = Node.CANCELLED;
// If we are the tail, remove ourselves.
if (node == tail && compareAndSetTail(node, pred)) { // node结点为尾结点，则设置尾结点为pred结点
// 比较并设置pred结点的next节点为null
compareAndSetNext(pred, predNext, null);
} else { // node结点不为尾结点，或者比较设置不成功
// If successor needs signal, try to set pred's next-link
// so it will get one. Otherwise wake it up to propagate.
int ws;
if (pred != head &&
((ws = pred.waitStatus) == Node.SIGNAL ||
(ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
pred.thread != null) { // (pred结点不为头结点，并且pred结点的状态为SIGNAL)或者
// pred结点状态小于等于0，并且比较并设置等待状态为SIGNAL成功，并且pred结点所封装的线程不为空
// 保存结点的后继
Node next = node.next;
if (next != null && next.waitStatus <= 0) // 后继不为空并且后继的状态小于等于0
compareAndSetNext(pred, predNext, next); // 比较并设置pred.next = next;
} else {
unparkSuccessor(node); // 释放node的前一个结点
}
node.next = node; // help GC
}
}
该方法完成的功能就是取消当前线程对资源的获取，即设置该结点的状态为 CANCELLED，接着我们再看 unparkSuccessor方法，源码如下：
1 // 释放后继结点
2 private void unparkSuccessor(Node node) {
3 /*
4 * If status is negative (i.e., possibly needing signal) try
5 * to clear in anticipation of signalling. It is OK if this
6 * fails or if status is changed by waiting thread.
7 */
8 // 获取node结点的等待状态
9 int ws = node.waitStatus;
10 if (ws < 0) // 状态值小于0，为SIGNAL -1 或 CONDITION -2 或 PROPAGATE -3
11 // 比较并且设置结点等待状态，设置为0
12 compareAndSetWaitStatus(node, ws, 0);
13
14 /*
15 * Thread to unpark is held in successor, which is normally
16 * just the next node. But if cancelled or apparently null,
17 * traverse backwards from tail to find the actual
18 * non-cancelled successor.
19 */
20 // 获取node节点的下一个结点
21 Node s = node.next;
22 if (s == null || s.waitStatus > 0) { // 下一个结点为空或者下一个节点的等待状态大于0，即为CANCELLED
23 // s赋值为空
24 s = null;
25 // 从尾结点开始从后往前开始遍历
26 for (Node t = tail; t != null && t != node; t = t.prev)
27 if (t.waitStatus <= 0) // 找到等待状态小于等于0的结点，找到最前的状态小于等于0的结点
28 // 保存结点
29 s = t;
30 }
31 if (s != null) // 该结点不为为空，释放许可
32 LockSupport.unpark(s.thread);
33 }
该方法的作用就是为了释放node节点的后继结点。对于cancelAcquire与unparkSuccessor方法，如下示意图可以清晰的表示：
其中 node为参数，在执行完 cancelAcquire方法后的效果就是 unpark了 s结点所包含的 t4线程。现在，再来看 acquireQueued方法的整个的逻辑。逻辑如下：
【1】判断结点的前驱是否为 head并且是否成功获取(资源)。
【2】若步骤1均满足，则设置结点为head，之后会判断是否 finally模块，然后返回。
【3】若步骤2不满足，则判断是否需要park当前线程，是否需要park当前线程的逻辑是判断结点的前驱结点的状态是否为SIGNAL，若是，则park当前结点，否则，不进行park操作。
【4】若 park了当前线程，之后某个线程对本线程unpark后，并且本线程也获得机会运行。那么，将会继续进行步骤①的判断。
**类的核心方法 release：**以独占模式释放对象，其源码如下：
1 public final boolean release(int arg) {
2 if (tryRelease(arg)) { // 释放成功
3 // 保存头结点
4 Node h = head;
5 if (h != null && h.waitStatus != 0) // 头结点不为空并且头结点状态不为0
6 unparkSuccessor(h); //释放头结点的后继结点
7 return true;
8 }
9 return false;
10 }
其中，tryRelease的默认实现是抛出异常，需要具体的子类实现，如果 tryRelease成功，那么如果头结点不为空并且头结点的状态不为0，则释放头结点的后继结点，unparkSuccessor方法已经分析过，不再累赘。
通过ReentrantLock理解AQS：ReentrantLock中公平锁和非公平锁在底层是相同的，这里以非公平锁为例进行分析。在非公平锁中，有一段这样的代码：
1 // java.util.concurrent.locks.ReentrantLock
2
3 static final class NonfairSync extends Sync {
4 ...
5 final void lock() {
6 if (compareAndSetState(0, 1))
7 setExclusiveOwnerThread(Thread.currentThread());
8 else
9 acquire(1);
10 }
11 ...
12 }
看一下这个Acquire是怎么写的：
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 public final void acquire(int arg) {
4 if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
5 selfInterrupt();
6 }
再看一下tryAcquire方法：
1 // java.util.concurrent.locks.AbstractQueuedSynchronizer
2
3 protected boolean tryAcquire(int arg) {
4 throw new UnsupportedOperationException();
5 }
可以看出，这里只是AQS的简单实现，具体获取锁的实现方法是由各自的公平锁和非公平锁单独实现的（以ReentrantLock为例）。如果该方法返回了True，则说明当前线程获取锁成功，就不用往后执行了；如果获取失败，就需要加入到等待队列中。下面会详细解释线程是何时以及怎样被加入进等待队列中的。
九、AQS 总结
对于 AbstractQueuedSynchronizer的分析，最核心的就是 sync queue的分析。
【1】每一个结点都是由前一个结点唤醒；
【2】当结点发现前驱结点是 head并且尝试获取成功，则会轮到该线程运行。
【3】condition queue中的结点向 sync queue中转移是通过 signal操作完成的。
【4】当结点的状态为 SIGNAL时，表示后面的结点需要运行。
十、大厂面试问题
【1】什么是 AQS? 为什么它是核心?
【2】AQS的核心思想是什么? 它是怎么实现的? 底层数据结构等？
【3】AQS有哪些核心的方法?
【4】AQS定义什么样的资源获取方式? AQS定义了两种资源获取方式：独占(只有一个线程能访问执行，又根据是否按队列的顺序分为公平锁和非公平锁，如ReentrantLock) 和共享(多个线程可同时访问执行，如Semaphore、CountDownLatch、 CyclicBarrier )。ReentrantReadWriteLock可以看成是组合式，允许多个线程同时对某一资源进行读。
【4】AQS底层使用了什么样的设计模式?
【5】AQS的应用示例?
扫一扫
1468
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
