介绍
上一篇，主要是介绍了多线程之间请求锁的流程。而ReentrantLock还提供了Condition实现，拓展了多线程之间协作功能。这些功能实际上由AbstractQueuedSynchronizer中内部实现的ConditionObject提供，ReentrantLock中只提供newCondition()获取Condition的方法。ConditionObject实现Condition接口，通过firstWaiter、lastWaiter这两个Node类型的变量维护一个队列(之后这个队列称为预队列)。
过程
整个协作流程可以从await打头的几个方法中查看，这些方法在流程上没有本质区别，只是多了状态验证的逻辑，所以这里分析仅awaitUninterruptibly()方法,其他几个方法不作赘述，先看看awaitUninterruptibly()源码，对流程有个大致了解：
//最基础的等待流程直接看这个awaitUninterruptibly()方法
public final void awaitUninterruptibly() {
//创建一个node，并添加到Condition中的链表中，
Node node = addConditionWaiter();
//释放锁
int savedState = fullyRelease(node);
boolean interrupted = false;
//检查node是否在AbstractQueuedSynchronizer的链表中(主队列)
while (!isOnSyncQueue(node)) {
LockSupport.park(this);
if (Thread.interrupted())
interrupted = true;
}
//请求锁
if (acquireQueued(node, savedState) || interrupted)
selfInterrupt();
}
Condition的整个流程分解为五个步骤(这样能让我更好的理顺Condition的脉络)：准备(线程1) > 等待(线程1) > 通知(线程2) > 被通知(线程1) > 结束(线程1)。下面根据步骤顺序查看源码。
准备
这个步骤主要方法有两个，addConditionWaiter()、fullyRelease(Node node)。
fullyRelease(Node node)是释放锁，返回锁的重入次数。
主要看addConditionWaiter()中都干了什么：
private Node addConditionWaiter() {
Node t = lastWaiter;
//首先清理一遍队列中被取消的节点
if (t != null && t.waitStatus != Node.CONDITION) {
unlinkCancelledWaiters();
t = lastWaiter;
}
//condition的节点使用nextWaiter链成队列，针对主队列中Node做区分
Node node = new Node(Thread.currentThread(), Node.CONDITION);
if (t == null)
firstWaiter = node;
else
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)
firstWaiter = next;
else
trail.nextWaiter = next;
if (next == null)
lastWaiter = trail;
}
else
trail = t;
t = next;
}
}
先是调用unlinkCancelledWaiters()移除队列中某些状态的Node，t.waitStatus != Node.CONDITION这个条件相对宽泛，被移除的节点将不止是CANCELLED，SIGNAL状态的Node也会被移除。
然后new一个初始状态为初始状态时CONDITION的Node，然后将新Node对象赋值给lastWaiter节点的nextWaiter，并且将lastWaiter也赋值为新Node对象。
如果预队列为没有Node，那么将firstWaiter和lastWaiter都设置为这个刚刚new出来的Node。因为只能用Node节点中的nextWaiter变量，所以预队列遍历时只能从firstWaiter开始。
预队列使用Node对象中nextWaiter变量维护队列，而AbstractQueuedSynchronizer中的队列(之后称为主队列)使用的是Node的prev和next两个变量，预队列和主队列的Node就有了一个明显的区别，就是预队列中的Node的prev和next都是null。
等待
将线程添加到预队列中之后，当前线程已释放锁，通过isOnSyncQueue(Node node)方法检查刚刚创建的节点是否在主队列中：
final boolean isOnSyncQueue(Node node) {
if (node.waitStatus == Node.CONDITION || node.prev == null)
return false;
if (node.next != null)
return true;
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;
}
}
如果线程的检点一直都不在主队列中，isOnSyncQueue(Node node)返回false，将一直停留在这个while循环处。
补充说明一下，预队列节点和主队列节点的区别就是Node的prev和next是否为null，如果prev和next不在是null，间接表明这个Node在主队列中。什么时候预队列中的Node的prev或next会被赋值呢？下面马上就会说到。
通知
线程进入阻塞状态后，通知步骤将由另一个线程执行Condition中的signal()和signalAll()方法：
public final void signal() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignal(first);
//signalAll中执行的方法是doSignalAll(first);
}
private void doSignal(Node first) {
do {
if ( (firstWaiter = first.nextWaiter) == null)
lastWaiter = null;
first.nextWaiter = null;
} while (!transferForSignal(first) &&
(first = firstWaiter) != null);
}
private void doSignalAll(Node first) {
lastWaiter = firstWaiter = null;
do {
Node next = first.nextWaiter;
first.nextWaiter = null;
transferForSignal(first);
first = next;
} while (first != null);
}
在通知前，会检查当前的线程是否持有锁，如果未持有锁，将会直接返回
signal()和signalAll()总体上差别不大，只是signalAll()会通知整个预队列中的线程。signal()只要transferForSignal(Node node)返回true就结束。
再来看看transferForSignal(Node node)中做了什么：
final boolean transferForSignal(Node node) {
//节点的状态被其他线程修改
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
//添加到主队列中
Node p = enq(node);
int ws = p.waitStatus;
//修改状态为SIGNAL
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
LockSupport.unpark(node.thread);
return true;
}
它先修改一次Node的节点，然后添加主队列(这个时候Node的prev被初始化了），然后才将Node的状态修改为SIGNAL，最后唤醒Node中的线程。这样通知就完成了。
为什么要修改两次Node的状态呢？
因为考虑到使用ConditionObject是多线程场景，可能会有多个线程同时在操作预队列中同一个Node，既有检查Node的状态将它移除出预队列的，也有将它添加到主队列的，第一次修改时，让多个线程使用CAS修改这个节点状态，修改成功的，继续接下来的流程，修改失败的线程直接返回false(一个很有效的failed fast的实现)，跳过这个Node，第二次修改，则是激活Node，虽然在这里Doug Lea大佬用了if语句流程，但是条件基本可以看做是true，我倾向于是Doug Lea大佬为了防止一些意想不到的多线程场景的双保险。
被通知
再回到等待线程的流程中，这个时候这个线程被唤醒，会重新进入isOnSyncQueue(Node node)，现在结合通知步骤的操作再来看那些if的条件语句：
final boolean isOnSyncQueue(Node node) {
if (node.waitStatus == Node.CONDITION || node.prev == null)
return false;
if (node.next != null)
return true;
return findNodeFromTail(node);
}
node.waitStatus是SIGNAL，node.prev不是null，检查node.next是否为null、调用findNodeFromTail(Node node)都是为了确认node已经完全添加到主队列中了。
当node.next == null时，使用findNodeFromTail(Node node)方法排除node在enq(Node node)中的CAS设置tail节点的操作一直失败，不能真正的从主队列中遍历到这个node的情况。
正常情况下isOnSyncQueue(Node node)返回true后，结束while循环，进入返回阶段。
返回
这个阶段，就是排排坐，分果果了，Node进入主队列排队等待，最后获取到锁，回顾一下awaitUninterruptibly()方法：
public final void awaitUninterruptibly() {
Node node = addConditionWaiter();
int savedState = fullyRelease(node);
boolean interrupted = false;
while (!isOnSyncQueue(node)) {
LockSupport.park(this);
if (Thread.interrupted())
interrupted = true;
}
if (acquireQueued(node, savedState) || interrupted)
selfInterrupt();
}
之前重入锁的次数savedState，在重新请求锁时，作为参数传入，在被ConditionObject通知之后，重新将锁的持有状态恢复到使用等待方法之前。
总结
基本使用
几个等待的方法使用方法一样，这里使用await()做示范：
- 通过ReentrantLock对象创建Condition对象；
- 线程1先持有锁，然后使用Condition对象，调用
await()； - 另一个线程，线程2持有锁，然后使用这个Condition对象，调用
signal()或者signalAll()； - 线程1苏醒，请求锁，继续后面的代码流程，结束。
整个使用过程和synchronized关键字中使用wait()、notify()和notifyAll()的过程很像。
特性
和ReentrantLock相似，提供了相对来讲比较稳定、合理的线程协作组件，无需自己重新实现一套类似的逻辑代码，并且提供了各种可设置超时时间的等待方法，使用起来也比较方便。
为什么推荐使用Condition，而不是synchronized关键字呢？
因为Condition接口本身的实现类会实现一些额外的功能，最基本的就是可超时，可中断这种有效防止死锁的逻辑，另外和实现了一些周边的统计功能，比如,hasWaiters(ConditionObject condition)检查当前是否有线程正在等待的线程;getWaitQueueLength(ConditionObject condition)检查当前等待线程的个数；getWaitingThreads(ConditionObject condition)查询具体等待的线程等等。这些方法的实现，都让我们能够更方便的监控线程的工作状态。
