AbstractQueuedSynchronizer為鎖機制維護了一個隊列，需要獲取鎖的線程們排在隊列中，只有排在隊首的線程才有資格獲取鎖。
ConditionObject是AbstractQueuedSynchronizer的內部類，它為鎖機制維護了另一個隊列，如果線程排在了該隊列中，說明這個線程需要在某種條件滿足后，才被喚醒。
前一個隊列是用于鎖的爭用的，稱之為syn queue。后一個隊列是用于條件等待的，稱之為condition queue。這兩個隊列之間是這樣協(xié)作的：當線程拿到鎖后，發(fā)現條件未滿足，便釋放鎖并掛到condition queue中去；當條件滿足后，線程會被喚醒，并掛到syn queue中去重新獲取鎖。具體的應用場景可見Java--Lock&Condition的理解中提到的生產者和消費者模型。
本文主要是對ConditionObject的實現做簡單的介紹。
Condition queue
ConditionObject主要是維護了一個condition queue，代碼如下所示
<pre>
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;
......
}
</pre>
condition queue也是一個Node隊列，這和syn queue同樣，不過syn queue是通過Node的prev和next指針形成的雙向隊列，而condition queue則是通過Node的nextWaiter形成的單向隊列。ConditionObject僅是記錄了condition queue的隊首和隊尾。
下面結合代碼簡述一下ConditionObject中幾個方法。
awaitUninterruptibly()
該方法就是當前線程要在某個條件上等待，要加入condition queue了。
步驟：
- 掛入condition queue；
- 釋放鎖；
- 掛起線程；
- 線程喚醒后重新嘗試獲取鎖。
代碼及注釋如下。
<pre>
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();
}
</pre>
這里面有個while，用來判斷線程是不是在syn queue里。針對這個循環(huán)可做兩點說明：
- node由addConditionWaiter()返回，是一個waitStatus=Node.CONDITION的node，所以，第一次執(zhí)行判斷時，必入循環(huán)，當前線程被掛起；
- 線程被喚醒，從掛起處繼續(xù)執(zhí)行，此時，會繼續(xù)執(zhí)行while內的判斷。直到確認當前線程已經在syn queue隊列上，才會嘗試獲取鎖。那么，node又是被誰放到syn queue中的呢？是和await()方法對應的signal()方法。
其中
addConditionWaiter()是ConditionObject的私有方法
fullyRelease()和isOnSyncQueue()是AbstractQueuedSynchronizer為Conditions實現的方法。
addConditionWaiter()
將當前線程掛入condition queue，代碼及注釋如下。
<pre>
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;
}
</pre>
該方法分為兩步。因為Node是從隊尾加入condition queue的，所以第一步是判斷condition queue的隊尾是否已經被cancel了，如果是，就調用unlinkCancelledWaiters()從隊頭開始將所有的cancelled node都出隊。清理完cancelled node后，隊尾就是有效的node了，此時，新建一個關聯到當前線程的node，將該node添加到隊列中，并設置為新的隊尾。
unlinkCancelledWaiters()
清除隊列中所有的cancelled node。
<pre>
private void unlinkCancelledWaiters() {
Node t = firstWaiter;//當前節(jié)點（就好比for循環(huán)中的i）
Node trail = null;//記錄當前節(jié)點前面最近的一個有效節(jié)點（未被取消的節(jié)點）
while (t != null) {
Node next = t.nextWaiter;
if (t.waitStatus != Node.CONDITION) {//如果當前節(jié)點被取消了，就將當前節(jié)點出隊
t.nextWaiter = null;
if (trail == null)//如果tiral為空，說明當前節(jié)點前面沒有有效節(jié)點,而當前節(jié)點又被取消了
//說明從當前節(jié)點往前的所有節(jié)點都被取消了，隊首自然要往后更新
firstWaiter = next;
else
trail.nextWaiter = next;
if (next == null)
lastWaiter = trail;
}
else
trail = t;//沒有取消，則更新所謂“最近的有效節(jié)點”
t = next;//當前節(jié)點更新為下一個（就好比for循環(huán)中的++i）
}
}
</pre>
signal()
喚醒condition queue的隊首，主要的代碼其實就是對doSignal()的調用。
doSignal()
喚醒隊首，代碼及注釋如下。
<pre>
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);//如果遷移失敗了，說明原先的隊首被取消了，嘗試處理更新后的隊首
} //如果更新后的隊首為空，說明隊列已經被清空了，就無需再處理了
</pre>
doSignal()在源碼中有這么一句注釋"Split out from signal in part to encourage compilers to inline the case of no waiters".這句話的含義如下：
這里單獨實現doSignal()接口的意義在于，使得signal()的代碼看起來十分簡單，不會直接包括循環(huán)體，編譯器在編譯的時候，將更傾向于將signal()當做inline function。這樣，在沒有任何waiters（即condition queue為空，也即firstWaiter == null）的情況下， signal()作為inline function，性能將得到更明顯的提升。
transferForSignal()
將node從condition queue遷移到syn queue。
代碼及注釋如下。
<pre>
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;
}
</pre>
ConditionObject的方法介紹就到這里了，下面是對CAS和inline function的一些解釋。
對condition queue的操作未用任何CAS操作？
比如說addConditionWaiter()和singal()方法在修改隊首和隊尾，或是在修改nextWaiter指針時，都未使用任何CAS操作。這是因為，一個線程如果正在調用ConditionObject的方法的話，說明它一定獲得了ConditionObject所隸屬的鎖。此時，能夠保證一次性只有一個線程正在修改該鎖對應的condition queue。
在上文解釋的代碼中，只有transferForSignal()使用到了CAS方法。因為該方法是想要改變其他線程的狀態(tài)，而其他線程的狀態(tài)還可能因為其他原因改變，所以其中使用了CAS方法。
inline function
inline function提升性能之處在于，編譯器在編譯的時候，會將代碼整個替換到函數調用所在位置，省去了函數調用的耗時。
函數調用的耗時我倒是知道些，調用時需要保存現場信息，開辟新的堆棧，返回時還要恢復現場信息。
但是，為何只有簡短的函數適合內聯呢？這是因為內聯增大了代碼的體積。代碼在執(zhí)行的時候是要被加載到內存的。若函數A采取調用的方式，不論被引用了多少次，代碼本身就只占一份A的內存空間。若A采取內聯的方式，若被引用了兩次，代碼本身就要占兩份的內存空間。一旦A被更多的地方引用，代碼占用的內存就會顯著增大，從而影響到運行時的性能。
這里有篇針對inline function的問答，感覺挺好：
http://www.learncpp.com/cpp-tutorial/75-inline-functions/
為防止鏈接失效，特截圖一張吧。
