JAVA并发(1)-AQS(亿点细节)
AQS(AbstractQueuedSynchronizer), 可以说的夸张点，并发包中的几乎所有类都是基于AQS的。
一起揭开AQS的面纱
1. 介绍
为依赖 FIFO阻塞队列 的阻塞锁和相关同步器(semaphores, events等)的实现提供一个框架。 为那些依赖于原子state的同步器提供基础(CyclicBarrier、CountDownLatch等). 支持独占模式和共享模式, 不同的模式需要实现不同的方法.
引用这位大佬的图 http://www.cnblogs.com/waterystone/p/4920797.html
这个图是AQS整体结构，从图中可以看到，AQS维护着一个阻塞队列(当线程获取资源失败时，就会进入该队列，等待，直到被唤醒), state是一个共享的资源。
2. 源码剖析
我们先看看AQS的类图，
内部类: Node，阻塞队列维护的元素；ConditionObject, 支持独占模式下的子类用作Condition实现, 后面会讲到。先看看Node的结构。
static final class Node {
/** 表明阻塞一个共享模式的结点 */
static final Node SHARED = new Node();
/** 表明阻塞一个独占模式的结点 */
static final Node EXCLUSIVE = null;
/** waitStatus value to indicate thread has cancelled */
// 发生的情况: 中断或者超时
static final int CANCELLED = 1;
/** 表明后继节点需要被唤醒 */
// 发生的情况: 后继结点被park()阻塞，当目前的结点释放或取消，必须要unpark它的后继结点
static final int SIGNAL = -1;
/** waitStatus value to indicate thread is waiting on condition */
// 发生的情况: 当前结点在条件队列中(后面会讲解)
static final int CONDITION = -2;
/**
* waitStatus value to indicate the next acquireShared should
* unconditionally propagate
*/
// 发生的情况: 执行releaseShared后，需要传播释放其他结点。
// 在doReleaseShared中进行设置。(后面讲解这个状态的必要性)
// 在共享模式下，才会用到
static final int PROPAGATE = -3;
/** 结点的状态, 初始值为0*/
volatile int waitStatus;
volatile Node prev;
volatile Node next;
volatile Thread thread;
....
}
tip: waitStatus > 0, 即 CANCELLED， 此时的结点不正常。
AQS使用了模板模式, 自主选择重新定义以下方法
- tryAcquire - 独占模式
- tryRelease - 独占模式
- tryAcquireShared - 共享模式
- tryReleaseShared - 共享模式
- isHeldExclusively
调用这些方法，都会引发UnsupportedOperationException，后面的文章将通过其子类，来讲解它们的实现。
有了这些知识后，我们从下面这几个关键的共有方法入手去讲解AQS
- acquire(int arg) - 独占模式
- release(int arg) - 独占模式
- acquireShared(int arg) - 共享模式
- releaseShared(int arg) - 共享模式
2.1 acquire
独占模式下的获取资源，忽略中断。调用tryAcquire至少一次，若成功就返回。否则，将线程入队，并可能反复阻塞和接触阻塞，并调用tryAcquire直至成功。此方法可以用于实现 Lock.lock
public final void acquire(int arg) {
// (2.1.1)
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
tryAcquire在后面文章结合子类进行分析。
代码(2.1.1)中，此时调用了tryAcquire，获取资源失败，返回false，继续执行后续方法。
addWaiter -- Queuing utilities
使用当前线程和给定mode， 新建一个Node，并且将新建Node入队
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) {
// (2.1.2) 记住这个地方, 后面有个知识点会用到
node.prev = pred;
// (2.1.3)
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
// 插入node入队，初始化如果有必要
// 执行到这的情况:
// 1. 阻塞队列为空时，即tail == null
// 2. 代码(2.1.3), CAS失败
enq(node);
return node;
}
enq -- Queuing utilities
一直循环直到node入队成功
private Node enq(final Node node) {
for (;;) {
Node t = tail;
// 初始时，head与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;
}
}
}
}
经过了上面的操作，目前的线程已经加入了队尾，此时做的事情就是阻塞自己，等待资源释放并且获取，然后执行自己的操作
acquireQueued
以独占且不可中断的模式，获取已经在阻塞队列中的线程。若在等待时被中断，返回true
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
// 不断自旋直到获取到资源或被park
for (;;) {
final Node p = node.predecessor();
// 若node的前继结点是head，执行tryAcquire，尝试获取资源(可能刚好释放了资源，就可以不用阻塞)
// (2.1.4)
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
// 检测是否需要被park,若需要就进行park，并返回在等待时是否被中断
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
// 失败，发生的情况 1. 被中断 2. 超时.(其他方法调用该方法时，会发生)
if (failed)
cancelAcquire(node);
}
}
shouldParkAfterFailedAcquire -- Utilities for various versions of acquire
对获取资源失败的node，检测并获取结点。返回true，如果线程需要阻塞
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
// 前驱结点的状态为SIGNAL，此时就可以安心的park，等待前驱节点释放资源，然后唤醒自己
if (ws == Node.SIGNAL)
return true;
// 此时ws为CANCELLED
if (ws > 0) {
/*
* 前驱结点状态为CANCELLED，跳过前驱结点并重试， 直到前驱节点不为CANCELLED
*/
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
/*
* waitStatus此时的值要么是0要么是PROPAGATE.
* 需要把前驱结点状态设置为SIGNAL
*/
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
cancelAcquire -- Utilities for various versions of acquire
取消正在进行的获取资源的尝试
private void cancelAcquire(Node node) {
// Ignore if node doesn't exist
if (node == null)
return;
node.thread = null;
// Skip cancelled predecessors
Node pred = node.prev;
while (pred.waitStatus > 0)
node.prev = pred = pred.prev;
// 获取过滤后的前驱的后驱节点
Node predNext = pred.next;
node.waitStatus = Node.CANCELLED;
// node为tail，就直接从队列中删除
if (node == tail && compareAndSetTail(node, pred)) {
compareAndSetNext(pred, predNext, null);
} else {
int ws;
// 1. 前驱结点不是头结点，该结点不是老二
// 2. 满足以下任意一个条件：
// 2.1 此时的前驱结点状态为SIGNAL
// 2.2 此时的前驱结点状态为PROPAGATE或CONDITION，成功将状态设置为SIGNAL
// 3. 前驱节点的任务不为空
// 满足上面的条件，就将节点的前驱结点的next 指向 节点的后驱结点
if (pred != head &&
((ws = pred.waitStatus) == Node.SIGNAL || (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
pred.thread != null) {
Node next = node.next;
if (next != null && next.waitStatus <= 0)
compareAndSetNext(pred, predNext, next);
} else {
// 此时结点刚好是老二;
// 代码(2.1.4) 可以看出，头结点要么是哨兵结点，要么是已经获取到资源的结点。
// 此时唤醒node的后驱结点，是为了防止后驱结点一直阻塞
unparkSuccessor(node);
}
node.next = node; // help GC
}
}
unparkSuccessor
后驱结点存在一个在正在等待的结点，则唤醒它
private void unparkSuccessor(Node node) {
int ws = node.waitStatus;
// 将当前的结点的waitStatus设置为0，失去SIGNAL、PROPAGATE的含义
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
// (2.1.5)
Node s = node.next;
if (s == null || s.waitStatus > 0) {
s = null;
// [问题一] 为什么node的后驱结点为空，重新寻找是从后往前找
// 只要waitStatus <= 0, 都有机会被唤醒
for (Node t = tail; t != null && t != node; t = t.prev)
// (2.1.6)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
LockSupport.unpark(s.thread);
}
2.1.1 acquire流程图
根据上面的分析，整一个流程图
2.1.2 小结
根据acquire流程图，一句话小结其流程，尝试获取资源，失败则将新建node(当前线程及独占模式)入队，检测自己是否是老二，是老二就再一次尝试获取资源，成功就返回中断标志，不是老二就设置为SIGNAL，park自己，然后安心等待被唤醒。
2.2 release
独占模式下的释放资源。解除阻塞一个或多个线程，当tryRelease返回true时。此方法可以用于实现 Lock.unlock
public final boolean release(int arg) {
// tryRelease返回true，继续下面操作。
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
2.2.1 release流程图
因为release(int arg)的主要流程是在tryRelease和unparkSuccessor中，但是tryRelease又是在子类中实现，所以该流程图也可以看作unparkSuccessor的流程图
2.2.2 小结
根据release流程图， 一句话小结其流程， 释放资源，唤醒后驱没有被取消的结点。
下面讲讲AQS的另一种模式，共享模式
2.3 acquireShared
共享模式下获取资源，忽略中断。至少调用tryAcquireShared一次，成功就返回。否则，线程将入队，可能会重复的阻塞和解除阻塞，直到调用tryAcquireShared成功。成功获取到资源，将会唤醒后驱结点，若资源满足。
public final void acquireShared(int arg) {
// 在子类探究tryAcquireShared
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
对tryAcquireShared返回的参数，进行简单的介绍
- 返回负数表示失败；
- 返回零，随后的线程都不能获取到资源
- 返回正数，随后的线程可以获取到资源
此时tryAcquireShared的返回值是小于零，表示获取资源失败，进行下一步处理
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) {
int r = tryAcquireShared(arg);
// 若前驱结点是头结点且刚好释放了，尝试获取资源
// (2.3.1)
if (r >= 0) {
// 将当前node设置为head，并且尝试唤醒node的后驱结点
setHeadAndPropagate(node, r);
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
// 跟独占模式的处理是一样的
// (2.3.2)
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
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.
*/
// tips: h == null、(h = head) == null、s == null，是为了防止空指针的发生
// 执行到下面的情况:
// 1. propagate是tryAcquireShared返回的值。propagate(资源) > 0， 表示还有资源可以唤醒后面的结点。
// 否则，此时propagate = 0, 结合代码(2.3.1)
// 2. 旧的head的waitStatus < 0
// 旧的头结点释放了资源，执行了代码(2.3.4), 此时的waitStatus 为PROPAGATE(初始化为0)
// 3. 此时的head已经是当前结点了，后面若有结点(此时后面的结点在park)，
// 那么新head的waitStatus肯定为SIGNAL, 结合代码(2.3.2)
// 情况3，有可能会发生没必要的唤醒，因为此时去唤醒新head的后驱结点，但是此时还没
// 有释放资源，它后驱结点唤醒后，去获取资源，获取失败，又被park.
// 源码注释说到，虽然有争议，但是大多数情况下，需要去唤醒
// (2.3.3)
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
doReleaseShared();
}
}
代码(2.3.3)中, 为什么不只用propagate来判断是否唤醒后驱结点 [问题二]
doReleaseShared
共享模式下主要的释放资源的逻辑，唤醒后驱结点，确保线程不被挂起
private void doReleaseShared() {
/*
* Ensure that a release propagates, even if there are other
* in-progress acquires/releases. This proceeds in the usual
* way of trying to unparkSuccessor of head if it needs
* signal. But if it does not, status is set to PROPAGATE to
* ensure that upon release, propagation continues.
* Additionally, we must loop in case a new node is added
* while we are doing this. Also, unlike other uses of
* unparkSuccessor, we need to know if CAS to reset status
* fails, if so rechecking.
*/
for (;;) {
Node h = head;
if (h != null && h != tail) {
int ws = h.waitStatus;
if (ws == Node.SIGNAL) {
// (2.3.4)
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue; // loop to recheck cases
unparkSuccessor(h);
}
// (2.3.5)
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue; // loop on failed CAS
}
if (h == head) // loop if head changed
break;
}
}
2.3.1 acquireShared的流程图
2.3.2 小结
一句话小结acquireShared的流程，尝试获取资源，若获取到资源，资源还有剩余就去继续唤醒后驱结点，若尝试获取资源失败，就park自己，等待被唤醒。 跟acquire相比，最大的区别就是，获取到资源acquireShared，还会去尝试唤醒其后驱结点
2.4 releaseShared
Releases in shared mode. Implemented by unblocking one or more threads if tryReleaseShared returns true.
// 代码比较简单，就不分析了~
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}
2.5 问题解答
[问题一] 为什么在唤醒后驱结点时，node的后驱结点为空，需要重新从后往前找
// (2.1.2) 记住这个地方, 后面有个知识点会用到
node.prev = pred; // 1
// (2.1.3)
if (compareAndSetTail(pred, node)) { // 2
pred.next = node; // 3
return node;
}
仔细观察代码(2.1.2) 和(2.1.3), 此时添加结点相当于有三步，都不是原子性的，当执行到第二步时，就要唤醒后驱结点了，此时新增的结点只设置了前驱结点，队列设置了尾结点，但是没有设置后驱结点，如果从前往后查找的话，可能会丢失符合要求的结点。
[问题二]，代码(2.3.3)中, 为什么不只用propagate来判断是否唤醒后驱结点。
请看这位大佬的博客 讲的非常详细
大致意思就是,
我们假设有A、B、C、D四个线程，前两个释放资源的线程，后两个是争抢资源的线程，此时只有A或B释放了资源，C、D才可以被唤醒，假设我们不看PROPAGTE
时刻一: A线程释放资源，执行代码 (2.3.4)，head的waitStatus从SIGNAL(-1)变为了0
时刻二: C线程获取到资源，执行到代码(2.3.1), tryAcquireShared返回0
时刻三: B线程线程释放资源，执行代码 (2.3.4)，因为此时未改变头结点，head的waitStatus为0，不能unparkSuccessor
时刻四: 此时C执行到代码(2.3.3)，propagate(tryAcquireShared返回值)为0，C也不会去唤醒后驱结点，D线程就永远GG了
引用doReleaseShared注释中的一句话
status is set to PROPAGATE to ensure that upon release, propagation continues.
2.6 Condition
使用synchronized时，线程间通信使用wait, notify and notifyAll;而使用AQS实现的lock，线程间的通信就使用Condition中的await、signal...。Condition与Lock结合使用，同一个lock对应多个Condition。
public class ConditionObject implements Condition...
在AQS中，已经对Condition的方法进行了实现，子类想使用的话，只需要调用ConditionObject就行了
final ConditionObject newCondition() {
return new ConditionObject();
}
本来想跟着源码走，简简单单介绍一下Condition，但是源码有几处细节，让我头秃，在网上搜索别人的博客，这篇博客解开了我的疑惑，对Condition介绍的非常详细，写的非常的完美~
根据大佬的博客，那我们下面简单讲解Condition的两个常用方法
- await
- signal
2.6.1 await & signal
导致目前线程阻塞直到被唤醒或中断;调用await后，会将当前的线程封装成node，加入到条件队列中
public final void await() throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
// 添加结点到条件队列中
Node node = addConditionWaiter();
// 释放当前线程持有的锁
int savedState = fullyRelease(node);
int interruptMode = 0;
// 不在同步队列中，就park
// (2.6.1)
while (!isOnSyncQueue(node)) {
// 执行到这，当前线程会立即挂起
LockSupport.park(this);
// 运行到这的话，情况: 1. signal 2. 中断
// 检验中断
// (2.6.2)
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);
}
为了讲清楚代码(2.6.1)之后的逻辑，我们先看看signal的源码
将condition queue中等待最长的结点转移到sync queue中去，去争抢资源
public final void signal() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignal(first);
}
此时，执行signal的主要逻辑
private void doSignal(Node first) {
do {
if ( (firstWaiter = first.nextWaiter) == null)
lastWaiter = null;
// 将后驱结点置空
// (2.6.3)
first.nextWaiter = null;
} while (!transferForSignal(first) &&
(first = firstWaiter) != null);
}
将condition queue中的一个结点转移到sync queue中去
final boolean transferForSignal(Node node) {
// 这里表示当前已经被取消了。
// (2.6.4)
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
// 将当前结点放入sync queue的末尾， 此时返回的是当前结点的前驱结点(一定要注意)
Node p = enq(node);
int ws = p.waitStatus;
// 前驱结点被取消，或者设置SIGNAL状态失败，就直接唤醒当前线程, 唤醒 = 有资格去竞争锁了
// enq返回的是前驱结点，我人傻了，看成是返回当前线程，就一直觉得逻辑不对。
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
LockSupport.unpark(node.thread);
return true;
}
这里signal的逻辑就讲完了,总结一下:
- 在condition queue中找出等待时间最长且未被取消的结点， 转移到sync queue的队尾去，同时要在condition queue中删除该结点
- 若在sync queue中的该结点的前驱结点被取消了或设置SIGNAL状态失败，要直接唤醒它，叫它去竞争锁。
signalAll的主要逻辑和signal是一样的，差别就是signalAll会把所有在condition queue中的结点转移到sync queue中去，并清空所有在condition queue中的结点，下面只贴一下signalAll的主要代码，
private void doSignalAll(Node first) {
lastWaiter = firstWaiter = null;
do {
Node next = first.nextWaiter;
first.nextWaiter = null;
transferForSignal(first);
first = next;
} while (first != null);
}
我们再次回到await中去
public final void await() throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
// 添加结点到条件队列中
Node node = addConditionWaiter();
// 释放当前线程持有的锁
int savedState = fullyRelease(node);
int interruptMode = 0;
// 不在同步队列中，就park
// (2.6.1)
while (!isOnSyncQueue(node)) {
// 执行到这，当前线程会立即挂起
LockSupport.park(this);
// 运行到这的话，情况: 1. signal 2. 中断
// 检验中断
// (2.6.2)
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);
}
从代码(2.6.1)，继续讲解
isOnSyncQueue
一开始在条件队列中，现在在sync queue中等待重新获取资源，如果有这种的node就返回true
final boolean isOnSyncQueue(Node node) {
if (node.waitStatus == Node.CONDITION || node.prev == null)
return false;
if (node.next != null) // If has successor, it must be on queue
return true;
/*
* node.prev can be non-null, but not yet on queue because
* the CAS to place it on queue can fail. So we have to
* traverse from tail to make sure it actually made it. It
* will always be near the tail in calls to this method, and
* unless the CAS failed (which is unlikely), it will be
* there, so we hardly ever traverse much.
*/
return findNodeFromTail(node);
}
findNodeFromTail
从尾部找寻结点
private boolean findNodeFromTail(Node node) {
Node t = tail;
for (;;) {
// 结合下面的enq代码以及图思考一下，会明白此方法的意义的
if (t == node)
return true;
if (t == null)
return false;
t = t.prev;
}
}
node.waitStatus == Node.CONDITION, 表示当前结点肯定在condition queue中。
为何是上面的那些条件?
我们上面看了转移到sync queue是用的enq方法
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
// (2.6.5)
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
结合代码(2.6.5),思考一下就知道isOnSyncQueue中条件设置的道理了，但是为何需要findNodeFromTail啦？ 这是需要补充一个知识点了，在多个线程执行enq时，只有一个线程会设置为tail成功，其余的都只是设置prev，就可能会出现下面图片中的情况，'多个尾巴'。一直不断自旋，最后会变成一个正常的链表。
此时线程的状态是，调用await后，将结点添加到条件队列中，且释放了自己持有的所有资源，并将自己park，此时等待被signal或者被中断。
public final void await() throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
// 添加结点到条件队列中
Node node = addConditionWaiter();
// 释放当前线程持有的锁
int savedState = fullyRelease(node);
int interruptMode = 0;
// 不在同步队列中，就park
// (2.6.1)
while (!isOnSyncQueue(node)) {
// 执行到这，当前线程会立即挂起
LockSupport.park(this); /// 我们在这被挂起了
// 运行到这的话，情况: 1. signal 2. 中断
// 检验中断
// (2.6.2)
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);
}
执行到代码(2.6.2), 我们直到可能是被signal或被中断了。现在要解决的是，
- 是否被中断?
- 何时被中断?
- 中断如何处理?
我们带着这三个问题，继续出发~
补充一个小知识点，AQS定义了三种情况中断的值
- THROW_IE, signal前被中断，要抛出InterruptedException
- REINTERRUPT， signal后被中断
- 0， 未被中断
关于REINTERRUPT这个中断，可以理解成，吃饭，吃完了但是还有一个菜没有上，问服务员，“如果没有炒，就不要了”，但是服务员告诉，菜已经下锅，所以这时候的中断就是REINTERRUPT，中断的太晚了。 -- 例子来自上面的那篇博客
我们继续看向代码(2.6.2)
checkInterruptWhileWaiting
private int checkInterruptWhileWaiting(Node node) {
return Thread.interrupted() ?
(transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT) :
0;
}
若被中断Thread.interrupted肯定为true
transferAfterCancelledWait
final boolean transferAfterCancelledWait(Node node) {
// 中断情况一: 此时结点还在condition queue中，肯定是signal前就被中断了
if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) {
// 这里还要加入到sync queue中，获取到锁才能抛出错，继续往后看
enq(node);
return true;
}
/*
* If we lost out to a signal(), then we can't proceed
* until it finishes its enq(). Cancelling during an
* incomplete transfer is both rare and transient, so just
* spin.
*/
// 中断情况二: 这里的情况就是signal后，node还没有执行enq，毕竟执行signal到执行enq还有几个步骤
// 此时就自旋，等待node转移到sync node中就行了
while (!isOnSyncQueue(node))
Thread.yield();
return false;
}
上面的代码已经注明了，各种情况的发生时机，此时我们来到了await的第二部分~
public final void await() throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
// 添加结点到条件队列中
Node node = addConditionWaiter();
// 释放当前线程持有的锁
int savedState = fullyRelease(node);
int interruptMode = 0;
// 不在同步队列中，就park
// (2.6.1)
while (!isOnSyncQueue(node)) {
// 执行到这，当前线程会立即挂起
LockSupport.park(this); /// 我们在这被挂起了
// 运行到这的话，情况: 1. signal 2. 中断
// 检验中断
// (2.6.2)
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
// 第二部分
// acquireQueued获取到锁，并返回是否被中断。
// 有一种情况需要提一下，acquireQueued返回true，上面的interruptMode = 0，
// 表示signal后，在获取锁的时候被中断了
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
// node还在condition上，说明是被取消了的node，清除它
if (node.nextWaiter != null) // clean up if cancelled
unlinkCancelledWaiters();
if (interruptMode != 0)
// 对上面得到的interruptMode做出回应
reportInterruptAfterWait(interruptMode);
}
reportInterruptAfterWait
private void reportInterruptAfterWait(int interruptMode)
throws InterruptedException {
if (interruptMode == THROW_IE)
throw new InterruptedException();
else if (interruptMode == REINTERRUPT)
selfInterrupt();
}
2.6.2 await与signal的流程图
2.6.3 小结
先讲讲await的流程，看起流程图有点吓人，其实很多步骤是对不同时机的中断操作的记录
当await被执行，下面简单总结下await的流程
- 将当前线程与CONDITION状态封装成node，加入到condition queue的末尾
- 释放线程之前获取的所有资源
- 若不在sync queue中，阻塞自己，等待被signal或被中断
- 获取中断操作的时机，并记录表示何时中断的值(interruptMode)
- 不管是怎么被唤醒的，都要去竞争资源，直到获得资源为止
- 最后对不同的中断值，作出不同的操作
signal的流程就相对于简单一点
- 获取condition queue的头结点
- 检验是否被取消，若被取消，就获取头结点的后驱结点，以此类推；
- 将结点从condition queue中转移到sync queue中，而且会从condition queue中删除该节点
- 若结点插入sync queue，得到的前驱结点，被取消了，或者CAS前驱结点状态为SIGNAL
失败，将直接unpark当前线程
3. 总结
Doug Lea，太秀了。AQS中有很多细枝末节的东西，只有自己去读了源码，理解为何这样做，你才会明白才会真正读懂AQS。
关于学习和写AQS文章时，看了一些博客，为我解答了自己的疑惑，慢慢加油，我也要向这些大佬看齐~
4. 参考
- 《Java并发编程之美》 - 这本书可以作为学习并发的入门书
- Java并发之AQS详解 - 引用了他的图片
- AbstractQueuedSynchronizer源码解读 - 为我解开了一些获取和释放资源的疑惑
- 逐行分析AQS源码(4)——Condition接口实现 - 为我解开了一些Condition的疑惑
- AQS论文 Doug Lea
~~# 5. 面试中问题
这是我的一个想法，若我博客中写过的知识，在面试中有问到过，我会记录下来，没有就是目前还没遇到过
