Condition的await-signal流程详解

转载请注明出处：http://blog.csdn.net/luonanqin

上一篇讲了ReentrantLock的lock-unlock流程，今天这篇讲讲Condition的await-signal流程。

Condition类图：

• Condition接口包含了多种await方式和两个通知方法
• ConditionObject实现了Condition接口，是AbstractQueuedSynchronizer的内部类
• Reentrantlock的newCondition方法返回与某个lock实例相关的Condition对象

和release队列一样，Condition队列也是虚拟队列，每个Node通过nextWaiter进行关联。因为Condition Node要变为release Node才可以解除阻塞，所以不需要prevWaiter，这一点下面会有说明。

大概的整个过程是：

调用await的线程都会进入一个Condition队列。调用signal的线程每一次都会从firstWaiter开始找出未取消的Condition Node放到release队列里，然后调用signal的线程在await或者unlock的时候执行release方法才有机会将其解除阻塞。相对于lock-unlock，正常的流程要简单一些，但是对于中断处理会更为复杂。

先看看调用await()至阻塞的过程

如图所示，该过程可分为三个步骤：

1. 新建Condition Node包装线程，加入Condition队列
2. 释放当前线程占用的锁
3. 阻塞当前线程

在阻塞当前线程之前，要判断Condition Node是否在release队列里。如果在的话则没必要阻塞，可直接参与锁竞争。关键代码如下：

 

 

       signal方法更简单一些，就是从firstWaiter开始，找到一个没有取消的Node放入release队列。但是即使一开始找到的Node没被取消，但是入队列的时候也可能会被取消，因此代码对这个情况做了点特殊处理。我根据自己的理解将代码做了如下解释：

我们可以看到，signal方法只是将Node修改了状态，并没有唤醒线程。要将修改状态后的Node唤醒，一种是再次调用await()，一种是调用unlock()。这两个方法内部都会执行release方法对release队列里的Node解除阻塞，关于这点我在上一篇文章里已经说明了。

 

下面我把调用await()的线程被解除阻塞后的流程也画了一下：

 

以上就是await和signal的详细流程。signalAll和signal很像，内部就是将Condition队列里所有的Node都加入到release队列中，仅此而已。

之后有时间我会把一些中断处理也用流程图描述下发出来。

参考资料：

怎么理解Condition   http://www.liuinsect.com/2014/01/27/how_to_understand_condition/