聊聊高併發（三十）解析java.util.concurrent各個元件（十二） 理解CyclicBarrier柵欄
這篇講講CyclicBarrier柵欄，從它的名字可以看出，它是可迴圈使用的。它的功能和CountDownLatch類似，也是讓一組執行緒等待，然後一起開始往下執行。但是兩者還是有幾個區別
1. 等待的物件不同。CountDownLatch的一組執行緒等待的是一個事件，或者說是一個計數器歸0的事件。而CyclicBarrier等待的物件是執行緒，只有執行緒都到齊了才往下執行
2. 使用方式不同，這個也是由等待的物件不同引起的，CountDownLatch需要呼叫await()來讓執行緒等待，呼叫countDown()來修改狀態，直到觸發狀態為0的事件。而CyclicBarrier只需要呼叫await()讓執行緒等待，當呼叫await()方法的執行緒數滿足條件，就自動喚醒所有執行緒往下執行
3. CyclicBarrier可以自動迴圈使用，當一次攔截被開啟後，會自動建立下一個攔截。CountDownLatch的計數器歸0後不能再次使用
4. 底層實現不同，CountDownLatch使用AQS來實現底層同步，CyclicBarrier基於更上層的ReetrantLock + Condition條件佇列實現
5. 失效機制不同，在CountDownLatch等待的執行緒如果被中斷或者超時取消，不會影響其他執行緒。而CyclicBarrier採用all-or-none的機制，要麼全部不通過，要麼全部都通過，也就是說一旦在CyclicBarrier等待的執行緒有一個被中斷或者超時取消，那麼其他所有在這個CyclicBarrier等待的執行緒都被喚醒，通過柵欄往下執行
6. CyclicBarrier支援執行緒全部通過之後的回撥功能，通過傳入一個Runnable物件，由最後一個到達的執行緒來執行。而CountDownLatch不支援回撥機制
下面看看CyclicBarrier的原始碼，它有一個內部類Generation來處理迴圈使用的問題，維護了一個broker狀態表示當前的柵欄是否失效。如果失效，可以重置柵欄的狀態。當柵欄被打破時，就設定當前generation的broker為true表示失效，並喚醒所有等待的執行緒，即all-or-none機制
private static class Generation { boolean broken = false; } private void nextGeneration() { // signal completion of last generation trip.signalAll(); // set up next generation count = parties; generation = new Generation(); } private void breakBarrier() { generation.broken = true; count = parties; trip.signalAll(); }
維護了一個ReentrantLock來作同步，並建立了一個相關的條件佇列Condition，使用Condition的await()方法讓執行緒在同一個條件佇列等待，使用Condition.signalAll()喚醒所有在通過一條件佇列等待的執行緒。
/** The lock for guarding barrier entry */
private final ReentrantLock lock = new ReentrantLock();
/** Condition to wait on until tripped */
private final Condition trip = lock.newCondition();維護了一個Runnable引用來支援回撥功能
/* The command to run when tripped */
private final Runnable barrierCommand;
public CyclicBarrier(int parties, Runnable barrierAction) {
if (parties <= 0) throw new IllegalArgumentException();
this.parties = parties;
this.count = parties;
this.barrierCommand = barrierAction;
}
維護了一個count來計數，當await()方法被呼叫一次, count就減1，直到count為0開啟柵欄。
private int count;可以看到CyclicBarrier的例項屬性都沒有使用volatile變數，那它怎麼保證狀態的可見性呢？CyclicBarrier使用了加顯式鎖的方式。我們知道顯式鎖和內建鎖一樣，都保證了可見性，有序性和原子性。
1. 進入鎖相當於讀volatile，會清空CPU快取，強制從記憶體讀取
2. 離開鎖相當於寫volatile，會把CPU寫緩衝區的資料強制重新整理到記憶體
CyclicBarrier常用支援普通的等待和限時的等待。最後都是落到了dowait()方法。
public int await() throws InterruptedException, BrokenBarrierException {
try {
return dowait(false, 0L);
} catch (TimeoutException toe) {
throw new Error(toe); // cannot happen;
}
}
public int await(long timeout, TimeUnit unit)
throws InterruptedException,
BrokenBarrierException,
TimeoutException {
return dowait(true, unit.toNanos(timeout));
}
來看看dowait方法
1. 必須先獲取鎖，保證了可見性，有序性，原子性
2. 判斷當前柵欄的狀態，如果已經失效，丟擲BrokerBarrierException異常
3. 如果執行緒被中斷，那麼讓柵欄失效，會喚醒所有等待執行緒往下執行
4. 執行一次dowait就對count減一，用index記錄下當前執行緒執行是的count值作為索引
5. 如果index == 0表示是最後到達的執行緒，可以開啟柵欄了。首先如果有回撥，就執行回撥。然後重置柵欄狀態，使之可以迴圈使用，返回0
6. 如果index不為0，表示不是最後到達的執行緒，就輪詢等待，這裡支援了限時操作，使用了Condition條件佇列的await()機制。直到超時或者柵欄被正常失效。柵欄失效後會使用Condition來喚醒所有在同一個條件佇列等待的執行緒。
private int dowait(boolean timed, long nanos)
throws InterruptedException, BrokenBarrierException,
TimeoutException {
final ReentrantLock lock = this.lock;
lock.lock();
try {
final Generation g = generation;
if (g.broken)
throw new BrokenBarrierException();
if (Thread.interrupted()) {
breakBarrier();
throw new InterruptedException();
}
int index = --count;
if (index == 0) { // tripped
boolean ranAction = false;
try {
final Runnable command = barrierCommand;
if (command != null)
command.run();
ranAction = true;
nextGeneration();
return 0;
} finally {
if (!ranAction)
breakBarrier();
}
}
// loop until tripped, broken, interrupted, or timed out
for (;;) {
try {
if (!timed)
trip.await();
else if (nanos > 0L)
nanos = trip.awaitNanos(nanos);
} catch (InterruptedException ie) {
if (g == generation && ! g.broken) {
breakBarrier();
throw ie;
} else {
// We're about to finish waiting even if we had not
// been interrupted, so this interrupt is deemed to
// "belong" to subsequent execution.
Thread.currentThread().interrupt();
}
}
if (g.broken)
throw new BrokenBarrierException();
if (g != generation)
return index;
if (timed && nanos <= 0L) {
breakBarrier();
throw new TimeoutException();
}
}
} finally {
lock.unlock();
}
}下面使用一個測試用例來測試CyclicBarrier的功能
1. 建立一個5個容量的CyclicBarrier，並設定回撥
2. 執行12個執行緒
package com.lock.test;
import java.util.concurrent.CyclicBarrier;
public class CyclicBarrierUsecase {
private CyclicBarrier barrier = new CyclicBarrier(5, new Runnable(){
@Override
public void run() {
System.out.println("Callback is running");
}
});
public void race() throws Exception{
System.out.println("Thread " + Thread.currentThread().getName() + " is waiting the resource");
barrier.await();
System.out.println("Thread " + Thread.currentThread().getName() + " got the resource");
}
public static void main(String[] args){
final CyclicBarrierUsecase usecase = new CyclicBarrierUsecase();
for(int i = 0; i < 12; i++){
Thread t = new Thread(new Runnable(){
@Override
public void run() {
try {
usecase.race();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}, String.valueOf(i));
t.start();
}
}
}
測試結果：
1. 可以看到5個執行緒在等待，直到滿5個執行緒到達之後開啟柵欄，這5個執行緒往下執行，並執行回撥
2. 柵欄被迴圈使用了，又有5個執行緒等待，直到滿5個執行緒到達又開啟柵欄往下執行，並執行回撥
3. 柵欄又被迴圈使用，但是隻有2個執行緒，不滿5個，就一直等待
Thread 0 is waiting the resource
Thread 4 is waiting the resource
Thread 5 is waiting the resource
Thread 3 is waiting the resource
Thread 2 is waiting the resource
Callback is running
Thread 1 is waiting the resource
Thread 0 got the resource
Thread 2 got the resource
Thread 6 is waiting the resource
Thread 7 is waiting the resource
Thread 4 got the resource
Thread 9 is waiting the resource
Thread 8 is waiting the resource
Thread 3 got the resource
Thread 5 got the resource
Callback is running
Thread 8 got the resource
Thread 1 got the resource
Thread 7 got the resource
Thread 6 got the resource
Thread 10 is waiting the resource
Thread 11 is waiting the resource
Thread 9 got the resource