1. 背景
在之前的AbstractQueuedSynchronizer源码解读中，介绍了AQS的基本概念、互斥锁、共享锁、AQS对同步队列状态流转管理、线程阻塞与唤醒等内容。其中并不涉及Condition相关的内容。本文主要介绍AQS中Condition的实现即ConditionObject类的源码。
Condition在JUC中使用很多，最常见的就是各种BlockingQueue了。
2. Condition是什么
java.util.concurrent.locks.Condition是JUC提供的与Java的Object中wait/notify/notifyAll类似功能的一个接口，通过此接口，线程可以在某个特定的条件下等待/唤醒。
与wait/notify/notifyAll操作需要获得对象监视器类似，一个Condition实例与某个互斥锁绑定，在此Condition实例进行等待/唤醒操作的调用也需要获得互斥锁，线程被唤醒后需要再次获取到锁，否则将继续等待。
而与原生的wait/notify/notifyAll等API不同的地方在于,JUC提供的Condition具有更丰富的功能，例如等待可以响应/不响应中断，可以设定超时时间或是等待到某个具体时间点。
此外一把互斥锁可以绑定多个Condition，这意味着在同一把互斥锁上竞争的线程可以在不同的条件下等待，唤醒时可以根据条件来唤醒线程，这是Object中的wait/notify/notifyAll不具备的机制
3. 代码解读
3.1 套路
JUC中Condition接口的主要实现类是AQS的内部类ConditionObject，它内部维护了一个队列，我们可以称之为条件队列，在某个Condition上等待的线程被signal/signalAll后，ConditionObject会将对应的节点转移到外部类AQS的等待队列中，线程需要获取到AQS等待队列的锁，才可以继续恢复执行后续的用户代码。
这里给出一个流程:
await流程:
1. 创建节点加入到条件队列
2. 释放互斥锁
3. 只要没有转移到同步队列就阻塞(等待其他线程调用signal/signalAll或是被中断)
4. 重新获取互斥锁
signal流程:
1. 将队列中第一个节点转移到同步队列
2. 根据情况决定是否要唤醒对应线程
这里以我之前在[AbstractQueuedSynchronizer源码解读]画的AQS状态流转图来说明下：
如果一个节点通过ConditionObject#await等方法调用初始化后，在被唤醒之后，会将状态切换至0，也即无状态，随后进入AQS的同步队列，此后就与一般的争锁无异了。
3.2 await方法
public final void await() throws InterruptedException {
// 对中断敏感。
if (Thread.interrupted())
throw new InterruptedException();
// 加到条件队列中。
Node node = addConditionWaiter();
// 完全释放互斥锁(无论锁是否可以重入)，如果没有持锁，会抛出异常。
int savedState = fullyRelease(node);
int interruptMode = 0;
/*
* 只要仍未转移到同步队列就阻塞。
* 转移的情况如下:
* 1. 其它线程调用signal将当前线程节点转移到同步队列并唤醒当前线程。
* 2. 其它线程调用signalAll。
* 3. 其它线程中断了当前线程,当前线程会自行尝试进入同步队列。
*/
while (!isOnSyncQueue(node)) {
LockSupport.park(this);
/*
* 获取中断模式。
* 在线程从park中被唤醒的时候，需要判断是否此时被中断，若中断则尝试转移到同步队列。
* 1. 中断且自行进入同步队列,返回THROW_IE(值-1),后续需要抛出InterruptedException。
* 2. 中断且未能自行进入同步队列,则说明有线程调用signal/signalAll唤醒线程并尝试转移到同步队列,
* 返回REINTERRUPT，后续重新中断线程。
* 3. 线程未被中断,返回0，此时需要重试循环判断是否上了同步队列。
*/
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
// 重新获取互斥锁过程中如果中断并且interruptMode不为"抛出异常",设置为REINTERRUPT。
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null) // clean up if cancelled
unlinkCancelledWaiters();
// 如果线程发生过中断则根据THROW_IE或是REINTERRUPT分别抛出异常或者重新中断。
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
}
private Node addConditionWaiter() {
Node t = lastWaiter;
/*
* 如果条件队列中最后一个waiter节点状态为取消,
* 则调用unlinkCancelledWaiters清理队列。
*/
if (t != null && t.waitStatus != Node.CONDITION) {
unlinkCancelledWaiters();
// 重读lastWaiter。
t = lastWaiter;
}
Node node = new Node(Thread.currentThread(), Node.CONDITION);
// t如果为null, 初始化firstWaiter为当前节点。
if (t == null)
firstWaiter = node;
else
// 将队尾的next连接到node。
t.nextWaiter = node;
lastWaiter = node;
return node;
}
/**
* 移除队列中所有取消节点。
*/
private void unlinkCancelledWaiters() {
Node t = firstWaiter;
// 记录上一个非取消节点。
Node trail = null;
while (t != null) {
Node next = t.nextWaiter;
if (t.waitStatus != Node.CONDITION) {
// 断开
t.nextWaiter = null;
if (trail == null)
// 如果trail为null,取当前节点的后继作为头节点的值(next可以为null)。
firstWaiter = next;
else
// 否则把trail连接到当前节点的后继。
trail.nextWaiter = next;
// 如果当前节点没有后继了, 更新lastWaiter为trail, 即上一个非取消节点。
if (next == null)
lastWaiter = trail;
}
else
trail = t;
t = next;
}
}
final boolean isOnSyncQueue(Node node) {
/*
* 节点状态为CONDITION一定是在条件队列,
* 或者如果prev为null也一定是在条件队列。
*
* 同步队列里的节点prev为null只可能是获取到锁后调用setHead清为null,
* 新入队的节点prev值是不会为null的。
* 另外,条件队列里节点是用nextWaiter来维护的，不用next和prev。
*/
if (node.waitStatus == Node.CONDITION || node.prev == null)
return false;
/*
* 如果next不为null,一定是在同步队列的。
* 这里值得一提的是在AQS的cancelAcquire方法中,
* 一个节点将自己移除出队列的时候会把自己的next域指向自己。
* 即node.next = node;
*
* 从GC效果上来看node.next = node和node.next = null无异,
* 但是这对此处next不为null一定在同步队列上来说,
* 这样可以将节点在同步队列上被取消的情况与普通情况归一化判断。
*/
if (node.next != null)
return true;
/*
* 有可能node.prev的值不为null,但还没在队列中,因为入队时CAS队列的tail可能失败。
* 这是从tail向前遍历一次,确定是否已经在同步队列上。
*/
return findNodeFromTail(node);
}
/**
* 从队列尾部向前遍历判断节点是否在队列中。
*/
private boolean findNodeFromTail(Node node) {
Node t = tail;
for (;;) {
if (t == node)
return true;
if (t == null)
return false;
t = t.prev;
}
}
private int checkInterruptWhileWaiting(Node node) {
/*
* 1. 线程未中断返回0
* 2. 线程中断且入同步队列成功,返回THROW_IE表示后续要抛出InterruptedException。
* 3. 线程中断且未能入同步队列(由于被signal方法唤醒),则返回REINTERRUPT表示后续重新中断。
*/
return Thread.interrupted() ?
(transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT) :
0;
}
final boolean transferAfterCancelledWait(Node node) {
if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) {
enq(node);
return true;
}
/*
* 上面CAS失败的原因是signal()方法被调用,状态已经被抢先更新了。
* 这时需要自旋等待节点成功进入同步队列,否则会影响后续的重新获取锁acquireQueued()方法。
* 因为acquireQueued必须在节点成功入队后才可以调用。
*/
while (!isOnSyncQueue(node))
Thread.yield();
return false;
}
/**
* THROW_IE则抛出InterruptedException,
* REINTERRUPT则重新中断当前线程。
*/
private void reportInterruptAfterWait(int interruptMode)
throws InterruptedException {
if (interruptMode == THROW_IE)
throw new InterruptedException();
else if (interruptMode == REINTERRUPT)
selfInterrupt();
}
static void selfInterrupt() {
Thread.currentThread().interrupt();
}
3.3 signal/signalAll方法
public final void signal() {
// 检查互斥锁持有情况。
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignal(first);
}
private void doSignal(Node first) {
do {
// 将firstWaiter设置为后继节点,如果为null,则置lastWaiter为null。
if ( (firstWaiter = first.nextWaiter) == null)
lastWaiter = null;
// 断开连接。
first.nextWaiter = null;
/*
* 如果转移失败并且下一个节点不为null,则重试。
* 在这里转移失败只可能因为节点被取消。
*/
} while (!transferForSignal(first) &&
(first = firstWaiter) != null);
}
public final void signalAll() {
// 检查互斥锁持有情况。
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignalAll(first);
}
private void doSignalAll(Node first) {
// 将firstWaiter和lastWaiter先清为null。
lastWaiter = firstWaiter = null;
// 从first开始一直遍历到第一个null节点。
do {
Node next = first.nextWaiter;
first.nextWaiter = null;
transferForSignal(first);
first = next;
} while (first != null);
}
final boolean transferForSignal(Node node) {
// 必须将状态从CONDITION流转到0,如果失败则说明节点被取消,因为这里不会存在signal的竞争。
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
// 插入同步队列。
Node p = enq(node);
int ws = p.waitStatus;
/*
* 如果前驱节点状态为取消或者无法将状态CAS到SIGNAL(比如可能前驱在此期间被取消了),
* 则需要唤醒参数node节点对应的线程,使其能开始尝试争锁。
*
* 如果将前驱状态切到SIGNAL了,则由相应线程在释放锁之后唤醒node节点对应线程。
*/
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
LockSupport.unpark(node.thread);
return true;
}
4. 思考与总结
至此，已经对ConditionObject的await/signal/signalAll方法源码进行了分析。对于中断不敏感的awaitUninterruptibly, 带有时限的awaitNanos由于大致套路与await无异，不作冗述。
ConditionObject的firstWaiter/lastWaiter以及AQS.Node的nextWaiter都是没有volatile修饰的。这是因为ConditionObject假设在await/signal/signalAll等方法的调用是已经持有互斥锁的。
个人认为ConditionObject这样的设计是有个问题的。即按照Condition接口的定义，在不持锁情况下调用await由子类决定如何处理，通常是抛出InterruptedException。但如果同时有持锁和不持锁的线程调用await方法，可能会对ConditionObject的内部队列造成破坏，后果就是有些成功调用await方法的线程可能永远没有办法被唤醒,因为无法通过队列追溯到它们。也就是非法调用会抛出异常，但仍然会对内部数据结构造成破坏，这其实是有一些不合理的，至少是可以改进的地方。
最简单的处理方式是，对于不持锁的请求抛出异常，不应该依靠await -> fullyRelease这一步来抛出异常，此时按照流程已经调用过addConditionWaiter了。可以在await这类方法前面与signal/signalAll一样预检查一次持锁情况:
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
整体而言,ConditionObject中代码对GC友好，逻辑缜密，读过之后受益匪浅。
