juc下Condition类解析
在使用Lock之前，我们使用的最多的同步方式应该是synchronized关键字来实现同步方式了。配合Object的wait()、notify()系列方法可以实现等待/通知模式。
Condition接口也提供了类似Object的监视器方法，与Lock配合可以实现等待/通知模式，但是这两者在使用方式以及功能特性上还是有差别的。Object和Condition接口的一些对比。摘自《Java并发编程的艺术》
一、我们首先来看一下整个Condition的运行机制及其java中Condition接口有哪些方法
当我们调用lock.newCondition()方法时，就会创建出一个等待队列（一个lock可以对应多个等待队列）。等我们调用condition的await()方法时，就会把当前的Node节点从阻塞队列中移到等待队列的末尾。
当使用singal()方法时，我们从对应等待队列的队头取出一个Node并且将其放入到阻塞队列中，如果是singalAll()方法,则把对应等待队列中所有的Node节点都移到阻塞队列中。
java中Condition接口中具体方法如下
二、AQS中ConditionObject的await方法分析
await()方法有多种变种，包括不响应中断的await，带有中断时间的await等等，但是基本思想都与await()方法相似,本文只分析await()方法。await()方法的分析如下
public final void await() throws InterruptedException {
//If current thread is interrupted, throw InterruptedException.
if (Thread.interrupted())
throw new InterruptedException();
//将调用await()方法的线程封装为一个node节点加入到条件队列中，并且返回该节点的一个引用
Node node = addConditionWaiter();
//完全释放掉当前线程对应的锁(将state的值置为0)
//为什么要释放锁呢？ 加着锁 挂起后，谁还能救你呢？
int savedState = fullyRelease(node);
//0 在condition队列挂起期间未接收过过中断信号
//-1 在condition队列挂起期间接收到中断信号了
//1 在condition队列挂起期间未接收到中断信号，但是迁移到“阻塞队列”之后 接收过中断信号。
int interruptMode = 0;
//isOnSyncQueue
//true:表示当前线程对应的node节点已经迁移到阻塞队列了
//false说明当前node仍然还在条件队列中，需要继续park！
while (!isOnSyncQueue(node)) {
//挂起当前线程，等待其他线程的唤醒
LockSupport.park(this);
//什么时候会被唤醒？都有几种情况呢？
//1.常规路径：外部线程获取到lock之后，调用了 signal()方法 转移条件队列的头节点到 阻塞队列， 当这个节点获取到锁后，会唤醒。
//2.转移至阻塞队列后，发现阻塞队列中的前驱节点状态 是 取消状态，此时会唤醒当前节点
//3.当前节点挂起期间，被外部线程使用中断唤醒..
//checkInterruptWhileWaiting ：就算在condition队列挂起期间 线程发生中断了，对应的node也会被迁移到 “阻塞队列”。
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
//执行到这里，就说明 当前node已经迁移到 “阻塞队列”了
//acquireQueued ：竞争队列的逻辑..
//条件一：返回true 表示在阻塞队列中 被外部线程中断唤醒过..
//条件二：interruptMode != THROW_IE 成立，说明当前node在条件队列内 未发生过中断
//设置interruptMode = REINTERRUPT
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
//考虑下 node.nextWaiter != null 条件什么时候成立呢？
//其实是node在条件队列内时 如果被外部线程 中断唤醒时，会加入到阻塞队列，但是并未设置nextWaiter = null。
if (node.nextWaiter != null) // clean up if cancelled
//清理条件队列内取消状态的节点..
unlinkCancelledWaiters();
//条件成立：说明挂起期间 发生过中断（1.条件队列内的挂起 2.条件队列之外的挂起）
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
}
/**
* 判断在等待过程中该节点是否被中断过
*/
private int checkInterruptWhileWaiting(Node node) {
//Thread.interrupted() 返回当前线程中断标记位，并且重置当前标记位 为 false 。
return Thread.interrupted() ?
//transferAfterCancelledWait 这个方法只有在线程是被中断唤醒时 才会调用！
(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 node the node
* @return true if cancelled before the node was signalled
*/
final boolean transferAfterCancelledWait(Node node) {
//条件成立：说明当前node一定是在 条件队列内，因为signal 迁移节点到阻塞队列时，会将节点的状态修改为0
if (compareAndSetWaitStatus(node, Node.CONDITION, 0)) {
//中断唤醒的node也会被加入到 阻塞队列中！！
enq(node);
//true：表示是在条件队列内被中断的.
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.
*/
//执行到这里有几种情况？
//1.当前node已经被外部线程调用 signal 方法将其迁移到 阻塞队列内了。
//2.当前node正在被外部线程调用 signal 方法将其迁移至 阻塞队列中 进行中状态..
while (!isOnSyncQueue(node))
Thread.yield();
//false:表示当前节点被中断唤醒时 不在 条件队列了..
return false;
}
/**
* 将处于取消状态的节点从等待队列中移除
*/
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)
firstWaiter = next;
else
trail.nextWaiter = next;
if (next == null)
lastWaiter = trail;
}
else
trail = t;
t = next;
}
}
/**
* Throws InterruptedException, reinterrupts current thread, or
* does nothing, depending on mode.
*/
private void reportInterruptAfterWait(int interruptMode)
throws InterruptedException {
if (interruptMode == THROW_IE)
throw new InterruptedException();
else if (interruptMode == REINTERRUPT)
selfInterrupt();
}
三、AQS中ConditionObject的addConditionWaiter方法分析
/**
* 将当前线程封装为一个Node加入等待队列中
* @return 返回封装的Node节点
*
* 流程
* 1、判断当前等待队列的尾节点否为取消状态（t != null && t.waitStatus != Node.CONDITION）
* 将处于取消状态的节点从等待队列中移除
* 2、将当前的线程封装为一个Node，并将其加入到等待队列中
*/
private Node addConditionWaiter() {
//获取当前条件队列的尾节点的引用 保存到局部变量 t中
Node t = lastWaiter;
// If lastWaiter is cancelled, clean out.
//条件一：t != null 成立：说明当前条件队列中，已经有node元素了..
//条件二：node 在 条件队列中时，它的状态是 CONDITION（-2）
// t.waitStatus != Node.CONDITION 成立：说明当前node已经被取消了..
if (t != null && t.waitStatus != Node.CONDITION) {
//将处于取消状态的节点从等待队列中移除
unlinkCancelledWaiters();
t = lastWaiter;
}
//将当前的线程封装为一个Node，并将其加入到等待队列中
Node node = new Node(Thread.currentThread(), Node.CONDITION);
if (t == null)
firstWaiter = node;
else
t.nextWaiter = node;
lastWaiter = node;
return node;
}
四、AQS中ConditionObject的fullyRelease方法分析
/**
* 用当前状态值调用释放,返回state的值
*/
final int fullyRelease(Node node) {
//完全释放锁是否成功，当failed失败时，说明当前线程是未持有锁调用 await方法的线程..（错误写法..）
//假设失败，在finally代码块中 会将刚刚加入到 条件队列的 当前线程对应的node状态 修改为 取消状态
//后继线程就会将 取消状态的 节点 给清理出去了..
boolean failed = true;
try {
//获取当前线程 所持有的 state值 总数！
int savedState = getState();
//绝大部分情况下：release 这里会返回true。
if (release(savedState)) {
//失败标记设置为false
failed = false;
//返回当前线程释放的state值
//为什么要返回savedState？
//因为在当你被迁移到“阻塞队列”后，再次被唤醒，且当前node在阻塞队列中是head.next 而且
//当前lock状态是state == 0 的情况下，当前node可以获取到锁，此时需要将state 设置为savedState.
return savedState;
} else {
throw new IllegalMonitorStateException();
}
} finally {
if (failed)
node.waitStatus = Node.CANCELLED;
}
}public final boolean release(int arg) {
//head什么情况下会被创建出来？
//当持锁线程未释放线程时，且持锁期间 有其它线程想要获取锁时，其它线程发现获取不了锁，而且队列是空队列，此时后续线程会为当前持锁中的
//线程 构建出来一个head节点，然后后续线程 会追加到 head 节点后面。
if (tryRelease(arg)) {
Node h = head;
//条件一:成立，说明队列中的head节点已经初始化过了，ReentrantLock 在使用期间 发生过 多线程竞争了...
//条件二：条件成立，说明当前head后面一定插入过node节点。
if (h != null && h.waitStatus != 0)
//唤醒后继节点..
unparkSuccessor(h);
return true;
}
return false;}
五、AQS中ConditionObject的isOnSyncQueue方法分析
final boolean isOnSyncQueue(Node node) {
//条件一：node.waitStatus == Node.CONDITION 条件成立，说明当前node一定是在
//条件队列，因为signal方法迁移节点到 阻塞队列前，会将node的状态设置为 0
//条件二：前置条件：node.waitStatus != Node.CONDITION ===>
// 1.node.waitStatus == 0 (表示当前节点已经被signal了)
// 2.node.waitStatus == 1 （当前线程是未持有锁调用await方法..最终会将node的状态修改为 取消状态..）
//node.waitStatus == 0 为什么还要判断 node.prev == null?
//因为signal方法 是先修改状态，再迁移。
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.
*/
/**
* 执行到这里，说明当前节点的状态为：node.prev != null 且 node.waitStatus == 0
* findNodeFromTail 从阻塞队列的尾巴开始向前遍历查找node，如果查找到 返回true,查找不到返回false
* 当前node有可能正在signal过程中，正在迁移中...还未完成...
*/
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;
}
}
六、AQS中singal的逻辑分析（singalAll逻辑相同）
public final void signal() {
//判断调用signal方法的线程是否是独占锁持有线程，如果不是，直接抛出异常..
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
//获取条件队列的一个node
Node first = firstWaiter;
//第一个节点不为null，则将第一个节点 进行迁移到 阻塞队列的逻辑..
if (first != null)
doSignal(first);
}
private void doSignal(Node first) {
do {
//firstWaiter = first.nextWaiter 因为当前first马上要出条件队列了，
//所以更新firstWaiter为 当前节点的下一个节点..
//如果当前节点的下一个节点 是 null，说明条件队列只有当前一个节点了...当前出队后，整个队列就空了..
//所以需要更新lastWaiter = null
if ( (firstWaiter = first.nextWaiter) == null)
lastWaiter = null;
//当前first节点 出 条件队列。断开和下一个节点的关系.
first.nextWaiter = null;
//transferForSignal(first)
//boolean：true 当前first节点迁移到阻塞队列成功 false 迁移失败...
//while循环 ：(first = firstWaiter) != null 当前first迁移失败，则将first更新为 first.next 继续尝试迁移..
//直至迁移某个节点成功，或者 条件队列为null为止。
} while (!transferForSignal(first) &&
(first = firstWaiter) != null);
}
final boolean transferForSignal(Node node) {
/*
* If cannot change waitStatus, the node has been cancelled.
*/
//cas修改当前节点的状态，修改为0，因为当前节点马上要迁移到 阻塞队列了
//成功：当前节点在条件队列中状态正常。
//失败：1.取消状态 （线程await时 未持有锁，最终线程对应的node会设置为 取消状态）
// 2.node对应的线程 挂起期间，被其它线程使用 中断信号 唤醒过...（就会主队进入到 阻塞队列，这时也会修改状态为0）
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
/*
* Splice onto queue and try to set waitStatus of predecessor to
* indicate that thread is (probably) waiting. If cancelled or
* attempt to set waitStatus fails, wake up to resync (in which
* case the waitStatus can be transiently and harmlessly wrong).
*/
//enq最终会将当前 node 入队到 阻塞队列，p 是当前节点在阻塞队列的 前驱节点.
Node p = enq(node);
//条件一：ws > 0 成立：说明前驱节点的状态在阻塞队列中是 取消状态,唤醒当前节点。
//条件二：前置条件(ws <= 0)，
//compareAndSetWaitStatus(p, ws, Node.SIGNAL) 返回true 表示设置前驱节点状态为 SIGNAl状态成功
//compareAndSetWaitStatus(p, ws, Node.SIGNAL) 返回false ===> 什么时候会false?
//当前驱node对应的线程 是 lockInterrupt入队的node时，是会响应中断的，外部线程给前驱线程中断信号之后，前驱node会将
//状态修改为 取消状态，并且执行 出队逻辑..
//前驱节点状态 只要不是 0 或者 -1 那么，就唤醒当前线程。
int ws = p.waitStatus;
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
LockSupport.unpark(node.thread);
return true;
}
