【源码角度】为什么AQS这样设计
AQS（AbstractQueuedSynchronizer，抽象同步队列器）是 一个基于 FIFO的双端队列。它分为独占模式和共享模式，本文主要围绕独占模式进行讲解，共享模式的原理和独占模式相似，最后会提一嘴。
场景代入
其实AQS模型在我们的生活中经常见到：坐火车时，一节车厢上只有一个厕所，如果厕所里有人，其他乘客只能排队，这些排队的乘客一般会有两种心情：
- 排在队头的，厕所的人怎么还不出来，我随时准备进去
- 队头后面的其他乘客，厕所的人出来也到不了我，不用急着进去，再刷会短视频，等我是队头再做好准备也不晚。
这句不是废话哦，我们怎么判断厕所里有没有人呢，可以推门试试能不能推开或者问话，是这样吗？不至于。火车上厕所门锁处有提示：如果乘客在里面上锁会变红，否则为绿色。
这其实就是AQS的设计思想，只不过AQS还考虑了模板和解耦。下面，上源码！
从源码看AQS
为什么state使用int类型
AQS 使用一个 volatile 修饰的 int 类型的成员变量 state 来表示同步状态（state用来说明厕所里面有没有人）。如果想要用一个变量来表示厕所有没有人，为什么不使用boolean类型呢，这不比int类型更省空间吗。这是因为AQS还有共享模式，共享模式下state可能的取值就不是2个了。
再来了解一下Node节点
Node是什么呢，其实就是在排队的乘客，一个Node就是一个在排队的乘客。我们知道，乘客不会一直排队，可以归为这样三种状态：排队中；进入厕所；并没有进入厕所但因为某些原因离开队伍。
所以Node也要有相应的状态，如源码中所示：
那如何利用这个先进先出的队列和 state 变量来管理多线程的同步状态呢？这些操作被封装成方法。有这么两种场景：
1） 尝试获取锁，获取不到立即返回；AQS 类中的 tryAcquire 方法
2） 获取锁，获取不到则进入同步队列直到获取锁。AQS 类中的 acquire 方法
protected boolean tryAcquire(int arg) {
throw new UnsupportedOperationException();
}
在 AQS 类的源码中，tryAcquire 方法被 protected 修饰，返回值是一个 boolean 类型代
表是否成功获得锁，tryAcquire 方法需要被子类重写这个方法，否则会抛出异常。这样设计
的目的是向上层提供方便，上层可以重写这个方法然后自由编写业务逻辑。
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
acquire 方法被 final 修饰，所以不能被子类重写。
注 意 上 面 最 后 一 行 的 selfInterrupt （ ） ， selfInterrupt 执行的前提是
acquireQueued(addWaiter(Node.EXCLUSIVE), arg)方法返回 true。这个方法返回的是线程在
获取锁的过程中是否发生过中断，返回 true 则证明发生过中断。所以 acquire 中的 selfInterrupt
其实是对获取锁的过程中发生过的中断的补充。为什么不直接用 isInterrupt()判断，是因为在获取锁的过程中，是通过park+死循环实现 的。每次 park 被唤醒之后都会重置中断状态，所以拿到锁的时候中断状态都是被重置后的。 上图的 addWaiter方法的作用：如果尝试获取锁失败，就讲当前线程封装成节点并插入同步队列，返回值为当前节点。插入同步队列的过程很神奇：首先会执行快速入队操作（其实是不完整的入队操作：相对于完整的入队操作，缺少了尾结点为空的处理）如果队列的尾节点为空或者第一次尝试 CompareAndSetTail（）操作失败，那么调用 enq 方法（这是完整的 入 队 操 作 ： 会 对 当 前 队 列 进 行 初 始 化 并 自 旋 地 通 过 CompareAndSetTail （）或CompareAndSetHead（）将当前节点插入直到入队成功），
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;
}
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
上面第一张图片是快速入队，第二张图片是完整入队 enq。两者相比确实只是少了对尾结点
为空时的处理。如果尾结点为空，会调用 compareAndSetHead（），这是一个 CAS 操作：
private final boolean compareAndSetHead(Node update) {
return unsafe.compareAndSwapObject(this, headOffset, null, update);
}
inal 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);
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
cancelAcquire 方法是将 node 的 waitStatue 修改为 CANCEL。
- 第 1 个 if语句： if（当前节点的前置节点是头结点&&当前线程 尝试获取锁成功）
假如当前 node 本来就不是队头或者就是tryAcquire(arg) 没有抢赢别人，就是走到下面 。注意：AQS 的 FIFO队列中头结点其实是虚节点（意思是说虚节点并不是当前需要去拿锁的节点，只是一个充当占位的摆设，第二个节点才是真正要去拿锁的节点，当第二个节点拿到锁之后他就会变成新的头结点，原来的头结点出队，所以在 AQS 的源码中经常会看见“判断当前节点的前置节点是否为头结点的判断语句”，本质就是为了判断当前节点有没有资格去拿锁） - 第 2 个 if 语句：if(boolean 当前线程需要被挂起（前驱节点，当前节点）&& parkAndCheckInterrupt挂起线程是否成功，这个方法会返回了 boolean Thread.Interrupted( ))
为什么要将线程挂起呢，直接自旋直到当前节点获得锁然后直接返回不就好了？逻辑上没问题，但自旋是 CPU的操作，如果大量的线程在自旋等待一定会出现性能问题。所以我们需要将那些还没有轮到他出队的那个线程挂起，再在适合的时间把它们唤醒，这样就能避免大量的自旋操作，能够极大地提升性能。
总结acquireQueued： 先初始化“是否发生过中断的标识”为 false。然后尝试获取锁，如果获取锁失败则会调用parkAndCheckInterrupt())方法 ，如果parkAndCheckInterrupt())返回了 true则证明发生过中断，将中断标记置为 true，最后会返回这个中断标记。
副本：Java中断机制
如果当前线程由于 wait 或 sleep 方法而处于等待状态，那么对该线程 interrupt将会使其抛出中断异常；如果该线程处于运行状态或者由于 park 方法挂起进入等待状态，那么 interrupt 只会改变这个 Thread 对象的一个中断状态值，并不会影响该线程继续运行。
回到AQS主线
如果 shouldParkAfterFailedAcquire(Node pred, Node node) 返回 true, 说明前驱节点的waitStatus==-1，是正常情况，那么当前线程需要被挂起，等待以后被唤醒，就等着前驱节点拿到锁，然后释放锁的时候叫你好了；如果返回 false, 说明当前不需要被挂起，为什么呢？仔细看 shouldParkAfterFailedAcquire(p, node)的源码，我们可以发现，其实第一次进来的时候，一般都不会返回 true 的，原因很简单，前驱节点的 waitStatus=-1 是依赖于后继节点设置的。也就是说，我都还没给前驱设置-1 呢，怎么可能是 true 呢，但是要看到，这个方法是套在循环里的，所以第二次进来的时候状态就是-1 了。
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
/*
* This node has already set status asking a release
* to signal it, so it can safely park.
*/
return true;
if (ws > 0) {
/*
* Predecessor was cancelled. Skip over predecessors and
* indicate retry.
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* waitStatus must be 0 or PROPAGATE. Indicate that we
* need a signal, but don't park yet. Caller will need to
* retry to make sure it cannot acquire before parking.
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
我们再来解释下为什么 shouldParkAfterFailedAcquire(p, node) 返回 false 的时候不直接挂起线程?这是因为经过这个方法后，当前节点的前一个节点有可能因为超时或者中断而取消阻塞退出同步队列因此设置了新的父节点，这个父节点有可能就已经是 head 了，恍然大悟。
释放锁
上面都在讲获取锁（acquire），下面讲一下释放锁（release）。
与 acquire 和 tryAcquire 获取锁对应，释放锁有 tryRelease 和 release。同样 tryRelease
向上层提供方便，不能直接使用，需要被子类重写；release 也是 final 修饰，不可被子类
重写。
protected boolean tryRelease(int arg) {
throw new UnsupportedOperationException();
}
在 release 中，如果尝试释放锁成功，那么紧接着就要去等待队列的其他节点，主要看
一下 unparkSuccessor 方法：
private void unparkSuccessor(Node node) {
/*
* If status is negative (i.e., possibly needing signal) try
* to clear in anticipation of signalling. It is OK if this
* fails or if status is changed by waiting thread.
*/
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
/*
* Thread to unpark is held in successor, which is normally
* just the next node. But if cancelled or apparently null,
* traverse backwards from tail to find the actual
* non-cancelled successor.
*/
Node s = node.next;
if (s == null || s.waitStatus > 0) {
s = null;
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 此时只是作为一个占位的虚节点，所以需要将它的 waitStatus 置为默认值 0.这样才不会影响其他函数的判断。接下来程序会从这个 FIFO 队列的尾结点开始搜索，找到除了 head 节点之外一个最靠前的并且 waitStatus<=0 的节点，并对其进行LockSupport.unpark(s.thread)操作，即唤醒这个之前被挂起的线程，让他起来争抢这个锁。被挂起的线程，一旦被唤醒，那么它将继续执行 acquireQueue 方法，自旋尝试获取锁。
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
最后为什么要 return Thread.interrupt（）呢？我们说过，如果线程被 prok 方法挂起而进入等待状态，那么 interrupt 只会改变这个 Thread 对象的一个中断状态值，并不会影响该线程继续运行，如果外部对这个线程调用 interrupt()是不会产生中断的，会改变这个Thread 对象的一个中断状态值，所以最后这句代码的作用就是：因为线程处于等待队列中无法响应外部的中断请求，只有当这个线程拿到锁之后，然后再根据这个线程的中断状态值进行响应。
AQS共享模式
上面讲了AQS的独占模式，其实共享模式和独占模式非常相似，它们的差异如下：
- 独占模式下：acquire 方法是线程获取共享资源的入口方法。
- 共享模式下：acquireShared 是线程获取共享资源的入口方法。
共享锁的 acquiredShared 方法其实与独占锁的 acquire 方法类似，tryAcquireShared 都是需要子类去实现，区别是独占锁的 tryAcquire 返回的是 boolean，而共享锁的tryAcquired 方法返回的是 int：
如果该值<0，则代表获取共享锁失败
如果该值=0，则代表获取共享锁成功，但随后其他线程获取共享锁会失败
如果该值>0，则代表获取共享锁成功，并且后续线程获取共享锁也可能成功
还有一个setHeadAndPropagate方法需要注意：
private void setHeadAndPropagate(Node node, int propagate) {
Node h = head; // Record old head for check below
setHead(node);
/*
* Try to signal next queued node if:
* Propagation was indicated by caller,
* or was recorded (as h.waitStatus either before
* or after setHead) by a previous operation
* (note: this uses sign-check of waitStatus because
* PROPAGATE status may transition to SIGNAL.)
* and
* The next node is waiting in shared mode,
* or we don't know, because it appears null
*
* The conservatism in both of these checks may cause
* unnecessary wake-ups, but only when there are multiple
* racing acquires/releases, so most need signals now or soon
* anyway.
*/
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
doReleaseShared();
}
}
setHeadAndPropagate 方法主要是为了设置获取锁的节点为头节点，并接下去直接唤
醒后继节点。