AbstractQueuedSynchronizer为锁机制维护了一个队列，需要获取锁的线程们排在队列中，只有排在队首的线程才有资格获取锁。

ConditionObject是AbstractQueuedSynchronizer的内部类，它为锁机制维护了另一个队列，如果线程排在了该队列中，说明这个线程需要在某种条件满足后，才被唤醒。

前一个队列是用于锁的争用的，称之为syn queue。后一个队列是用于条件等待的，称之为condition queue。这两个队列之间是这样协作的：当线程拿到锁后，发现条件未满足，便释放锁并挂到condition queue中去；当条件满足后，线程会被唤醒，并挂到syn queue中去重新获取锁。具体的应用场景可见Java--Lock&Condition的理解中提到的生产者和消费者模型。

本文主要是对ConditionObject的实现做简单的介绍。

Condition queue

ConditionObject主要是维护了一个condition queue，代码如下所示

public class ConditionObject implements Condition, java.io.Serializable {

//First node of condition queue.

private transient Node firstWaiter;

//Last node of condition queue.

private transient Node lastWaiter;

......

}

condition queue也是一个Node队列，这和syn queue同样，不过syn queue是通过Node的prev和next指针形成的双向队列，而condition queue则是通过Node的nextWaiter形成的单向队列。ConditionObject仅是记录了condition queue的队首和队尾。

下面结合代码简述一下ConditionObject中几个方法。

awaitUninterruptibly()

该方法就是当前线程要在某个条件上等待，要加入condition queue了。

步骤：

挂入condition queue；

释放锁；

挂起线程；

线程唤醒后重新尝试获取锁。

代码及注释如下。

public final void awaitUninterruptibly() {

Node node = addConditionWaiter();//将当前线程挂入condition queue

int savedState = fullyRelease(node);//释放锁

boolean interrupted = false;

while (!isOnSyncQueue(node)) {//线程是不是在syn queue里

LockSupport.park(this);//挂起当前线程

if (Thread.interrupted())

interrupted = true;

}

if (acquireQueued(node, savedState) || interrupted) //被唤醒后则重新开始尝试获取锁

selfInterrupt();

}

这里面有个while，用来判断线程是不是在syn queue里。针对这个循环可做两点说明：

node由addConditionWaiter()返回，是一个waitStatus=Node.CONDITION的node，所以，第一次执行判断时，必入循环，当前线程被挂起；

线程被唤醒，从挂起处继续执行，此时，会继续执行while内的判断。直到确认当前线程已经在syn queue队列上，才会尝试获取锁。那么，node又是被谁放到syn queue中的呢？是和await()方法对应的signal()方法。

其中

addConditionWaiter()是ConditionObject的私有方法

fullyRelease()和isOnSyncQueue()是AbstractQueuedSynchronizer为Conditions实现的方法。

addConditionWaiter()

将当前线程挂入condition queue，代码及注释如下。

private Node addConditionWaiter() {

Node t = lastWaiter;

//如果队尾已经被cancel了，就清理一次condition queue，将所有的cancelled node出队

// If lastWaiter is cancelled, clean out.

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

unlinkCancelledWaiters();

t = lastWaiter;

}

//新建node，关联到当前线程，并加入condition queue

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

if (t == null)

firstWaiter = node;

else

t.nextWaiter = node;

lastWaiter = node;

return node;

}

该方法分为两步。因为Node是从队尾加入condition queue的，所以第一步是判断condition queue的队尾是否已经被cancel了，如果是，就调用unlinkCancelledWaiters()从队头开始将所有的cancelled node都出队。清理完cancelled node后，队尾就是有效的node了，此时，新建一个关联到当前线程的node，将该node添加到队列中，并设置为新的队尾。

unlinkCancelledWaiters()

清除队列中所有的cancelled node。

private void unlinkCancelledWaiters() {

Node t = firstWaiter;//当前节点(就好比for循环中的i)

Node trail = null;//记录当前节点前面最近的一个有效节点(未被取消的节点)

while (t != null) {

Node next = t.nextWaiter;

if (t.waitStatus != Node.CONDITION) {//如果当前节点被取消了，就将当前节点出队

t.nextWaiter = null;

if (trail == null)//如果tiral为空，说明当前节点前面没有有效节点,而当前节点又被取消了

//说明从当前节点往前的所有节点都被取消了，队首自然要往后更新

firstWaiter = next;

else

trail.nextWaiter = next;

if (next == null)

lastWaiter = trail;

}

else

trail = t;//没有取消，则更新所谓“最近的有效节点”

t = next;//当前节点更新为下一个(就好比for循环中的++i)

}

}

signal()

唤醒condition queue的队首，主要的代码其实就是对doSignal()的调用。

doSignal()

唤醒队首，代码及注释如下。

private void doSignal(Node first) {

do {

if ( (firstWaiter = first.nextWaiter) == null)//队首的nextWaiter是不是指向空(也即队列里是不是只有一个node，即队首)

//这一步同时更新了队首，相当于将原先的队首出队了

lastWaiter = null;

first.nextWaiter = null;

} while (!transferForSignal(first) &&//将队首迁移到syn queue

(first = firstWaiter) != null);//如果迁移失败了，说明原先的队首被取消了，尝试处理更新后的队首

} //如果更新后的队首为空，说明队列已经被清空了，就无需再处理了

doSignal()在源码中有这么一句注释"Split out from signal in part to encourage compilers to inline the case of no waiters".这句话的含义如下：

这里单独实现doSignal()接口的意义在于，使得signal()的代码看起来十分简单，不会直接包括循环体，编译器在编译的时候，将更倾向于将signal()当做inline function。这样，在没有任何waiters(即condition queue为空，也即firstWaiter == null)的情况下， signal()作为inline function，性能将得到更明显的提升。

transferForSignal()

将node从condition queue迁移到syn queue。

代码及注释如下。

final boolean transferForSignal(Node node) {

if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))//如果node被取消了，就无需再进行什么迁移操作了

return false;//迁移失败，返回后doSignal()会去处理下一个node

Node p = enq(node);//将node加入syn queue

int ws = p.waitStatus;

if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))//尝试唤醒node关联的线程

//没唤醒也没关系，已经加入syn queue了，总会被syn queue前面的node唤醒的

LockSupport.unpark(node.thread);

return true;

}

ConditionObject的方法介绍就到这里了，下面是对CAS和inline function的一些解释。

对condition queue的操作未用任何CAS操作？

比如说addConditionWaiter()和singal()方法在修改队首和队尾，或是在修改nextWaiter指针时，都未使用任何CAS操作。这是因为，一个线程如果正在调用ConditionObject的方法的话，说明它一定获得了ConditionObject所隶属的锁。此时，能够保证一次性只有一个线程正在修改该锁对应的condition queue。

在上文解释的代码中，只有transferForSignal()使用到了CAS方法。因为该方法是想要改变其他线程的状态，而其他线程的状态还可能因为其他原因改变，所以其中使用了CAS方法。

inline function

inline function提升性能之处在于，编译器在编译的时候，会将代码整个替换到函数调用所在位置，省去了函数调用的耗时。

函数调用的耗时我倒是知道些，调用时需要保存现场信息，开辟新的堆栈，返回时还要恢复现场信息。

但是，为何只有简短的函数适合内联呢？这是因为内联增大了代码的体积。代码在执行的时候是要被加载到内存的。若函数A采取调用的方式，不论被引用了多少次，代码本身就只占一份A的内存空间。若A采取内联的方式，若被引用了两次，代码本身就要占两份的内存空间。一旦A被更多的地方引用，代码占用的内存就会显著增大，从而影响到运行时的性能。

这里有篇针对inline function的问答，感觉挺好：

http://www.learncpp.com/cpp-tutorial/75-inline-functions/

为防止链接失效，特截图一张吧。

inline function