if (node.nextWaiter != null) // clean up if cancelled //@7

unlinkCancelledWaiters();

if (interruptMode != 0) //@8

reportInterruptAfterWait(interruptMode);

}

代码@1：检测当前线程的中断标记，如果中断位为1，则抛出异常。

代码@2：添加等待节点。就是一个简单的链表维护节点的操作，具体参照addConditionWaiter讲解。

代码@3：释放占有的锁，并获取当前锁的state,因为await实现的语意为Object.wait,释放锁并并等待条件的发生。当条件满足后，线程被唤醒后，第一步是需要获取锁，然后在上次await的下一条指令处继续执行。代码3就是实现上述语义的释放锁。

代码@4：isOnSyncQueue 当前节点是否在同步队列中，如果在同步阻塞队列中，则申请锁，去执行；如果不在同步队列中（在条件队列中），阻塞，等待满足条件，新增的节点，默认在条件队列中(Conditon)。isOnSyncQueue 源码解读在下文中；

代码@5：线程从条件等待被唤醒,唤醒后，线程要从条件队列移除，进入到同步等待队列，被唤醒有有如下两种情况，一是条件满足，收到singal信号，二是线程被取消（中断），该步骤是从条件队列移除，加入到同步等待队列，返回被唤醒的原因，如果是被中断，需要根据不同模式，处理中断。处理中断，也有两种方式：1.继续设置中断位；2：直接抛出InterruptedException。请看下文关于checkInterruptWhileWaiting的源码解读。

代码@6：运行到代码6时，说明线程已经结束了释放锁，从条件队列移除，线程运行，在继续执行业务逻辑之前，必须先获取锁。只有成功获取锁后，才会去判断线程的中断标志，才能在中断标志为真时，抛出InterruptException。

代码@7，执行一些收尾工作，清理整个条件队列：

代码@8，处理中断，是设置中断位，还是抛出InterruptException。

那我们先关注一下addConditionWaiter方法：

/**

• Adds a new waiter to wait queue.

• @return its new wait node

*/

private Node addConditionWaiter() {

Node t = lastWaiter;

// If lastWaiter is cancelled, clean out.

if (t != null && t.waitStatus != Node.CONDITION) { //@1

unlinkCancelledWaiters();

t = lastWaiter;

}

Node node = new Node(Thread.currentThread(), Node.CONDITION); //@2

if (t == null)

firstWaiter = node;

else

t.nextWaiter = node;

lastWaiter = node;

return node;

}

添加条件等待节点，根据链表的特征，直接在尾部节点的nextWaiter指向新建的节点，并将新建的节点设置为整个链表的尾部，首先要知道如下数据结构：

object {

Node firstWaiter;

Node lastWaiter;

node {

node nextWaiter;

该节点承载的业务数据，比如这里的Thread t;等

}

}

知道上述结构，其实整个链的数据维护，基本一目了然，自己都可以实现下面的逻辑。

代码@1,如果最后一个等待节点的状态不是Node.CONDITION,则，则先删除等待链中节点状态不为Node.CONDITION的节点。具体代码分析请参照下文unlinkCancelledWaiters的解读。

代码@2开始，就是普通链表的节点添加的基本方法。

清除等待节点方法。

/**

• Unlinks cancelled waiter nodes from condition queue.

• Called only while holding lock. This is called when

• cancellation occurred during condition wait, and upon

• insertion of a new waiter when lastWaiter is seen to have

• been cancelled. This method is needed to avoid garbage

• retention in the absence of signals. So even though it may

• require a full traversal, it comes into play only when

• timeouts or cancellations occur in the absence of

• signals. It traverses all nodes rather than stopping at a

• particular target to unlink all pointers to garbage nodes

• without requiring many re-traversals during cancellation

• storms.

*/

private void unlinkCancelledWaiters() {

Node t = firstWaiter; //

Node trail = null; //@1

while (t != null) {

Node next = t.nextWaiter;

if (t.waitStatus != Node.CONDITION) { // @3

t.nextWaiter = null;

if (trail == null) // @4

firstWaiter = next;

else

trail.nextWaiter = next; //@5

if (next == null) // @6

lastWaiter = trail;

}

else // @4

trail = t;

t = next;

}

}

该方法的思路为，从第一节点开始，将不等于Node.CONDITION的节点。

代码@1,设置尾部节点临时变量，用来记录最终的尾部节点。代码@1 第一次循环，是循环第一个节点，如果它的状态为Node.CONDITION, 则该链的头节点保持不变，设置临时尾节点为t,然后进行一个节点的判断，如果节点不为Node.CONDITION, 重置头节点的下一个节点，或尾部节点的下一个节点(@4,@5)。代码@6代表整个循环结束，设置 ConditionObject对象的lastWaiter为trail的值；

await步骤中，释放锁过程源码解析。释放锁的过程，逻辑为unlock,但该方法，返回当前锁的state,因为释放锁后，该方法在条件没有满足前提下，自身需要阻塞。被唤醒后，需要先尝试获取锁，然后才能执行接下来的逻辑。

/**

• Invokes release with current state value; returns saved state.

• Cancels node and throws exception on failure.

• @param node the condition node for this wait

• @return previous sync state

*/

final int fullyRelease(Node node) {

boolean failed = true;

try {

int savedState = getState();

if (release(savedState)) {

failed = false;

return savedState;

} else {

throw new IllegalMonitorStateException();

}

} finally {

if (failed)

node.waitStatus = Node.CANCELLED;

}

}

await，@4步骤中，isOnSyncQueue 源码解读：

/**

• Returns true if a node, always one that was initially placed on

• a condition queue, is now waiting to reacquire on sync queue.

• @param node the node

• @return true if is reacquiring

*/

final boolean isOnSyncQueue(Node node) {

if (node.waitStatus == Node.CONDITION || node.prev == null) // @1

return false;

if (node.next != null) // If has successor, it

【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】浏览器打开：qq.cn.hn/FTf 免费领取

must be on queue // @2

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);

}

代码@1,如果节点的状态为Node.CONDITION 或 node.prev == null,表明该节点在条件队列中，并没有加入同步阻塞队列（同步阻塞队列为申请锁等待的队列），await方法中，新增的节点，默认满足上述条件，所以返回false,表示在条件队列中，等待条件的发生，条件满足之前，当前线程应该阻塞。这里，先预留一个疑问，那node.prev在什么时候会改变呢？

代码@2,如果node.next不为空，说明在同步阻塞队列中。这个我想毫无疑问。当然也说明next域肯定是在进入同步队列过程中会设置值。

代码@3, 上面的注释也说的比较清楚，node.prev不为空，但也不在同步队列中，这个是由于CAS可能会失败，为了不丢失信号，从同步队列中再次选择该节点，如果找到则返回true,否则返回false,在这里，我就更加对node.prev在什么时候会设置值感兴趣了，请继续await方法向下看，总有水落石出的时候。

await @5 checkInterruptWhileWaiting 代码解读：

/*

• For interruptible waits, we need to track whether to throw

• InterruptedException, if interrupted while blocked on

• condition, versus reinterrupt current thread, if

• interrupted while blocked waiting to re-acquire.

*/

/** 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; // 直接抛出 InterruptedException 0:正常

/**

• Checks for interrupt, returning THROW_IE if interrupted

• before signalled, REINTERRUPT if after signalled, or

• 0 if not interrupted.

*/

private int checkInterruptWhileWaiting(Node node) {

return Thread.interrupted() ?

(transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT) :

0;

}

/**

• Transfers node, if necessary, to sync queue after a cancelled

• wait. Returns true if thread was cancelled before being

• signalled.

• @param current the waiting thread

• @param node its node

• @return true if cancelled before the node was signalled

*/

final boolean transferAfterCancelledWait(Node node) {

if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) { //@1

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.

*/

while (!isOnSyncQueue(node))

Thread.yield();

return false;

}

/**

• Inserts node into queue, initializing if necessary. See picture above.

• @param node the node to insert

• @return node’s predecessor

*/

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;

}

}

}

}

重点关注@1,首先需要知道一点，如果收到正常的singal()信号而被唤醒的节点【这个再singal方法时重点分析】，状态为Node.SINGAL,不会是Node.CONDITION状态，所以如果代码1compareAndSetWaitStatus设置成功，说明线程是调用了t.interrupt方法而使得LockSupport.park解除阻塞的，然后将该节点加入到同步队列中，使得 while( ! isOnSyncQueue(node)) 的条件为真，结束 await的等待条件触发语义，，进入到 抢占锁阶段。【再次重申Object wait语义，释放当前锁，然后等待条件的触发【条件队列】，，条件发生后，要先重新去抢占锁，获取锁则继续执行，否则阻塞在获取锁【同步队列】】，所以当 线程阻塞在  await 方法时，调用 t.interrupt方法时只是中断条件队列的等待，并不能马上取消执行，马上抛出InterrupterException。

await方法流程图：

1.2 signal()方法详解

---

/**

• Moves the longest-waiting thread, if one exists, from the

• wait queue for this condition to the wait queue for the

• owning lock.

• @throws IllegalMonitorStateException if {@link #isHeldExclusively}

•     returns {@code false}
  

*/

public final void signal() { // @1

if (!isHeldExclusively()) //如果当前线程不是锁的持有者，直接抛出异常。

throw new IllegalMonitorStateException();

Node first = firstWaiter;

if (first != null)

doSignal(first); //通知第一个等待者 //@2

}

/**

• Removes and transfers nodes until hit non-cancelled one or

• null. Split out from signal in part to encourage compilers

• to inline the case of no waiters.

• @param first (non-null) the first node on condition queue

*/

private void doSignal(Node first) {

do {

if ( (firstWaiter = first.nextWaiter) == null) // @3

lastWaiter = null;

first.nextWaiter = null;

} while (!transferForSignal(first) &&