☕【Java深層系列】「併發程式設計系列」讓我們一起探索一下CyclicBarrier的技術原理和原始碼分析

浩宇天尚 發表於 2022-01-24
Java

☕【Java深層系列】「併發程式設計系列」讓我們一起探索一下CyclicBarrier的技術原理和原始碼分析

CyclicBarrier和CountDownLatch

CyclicBarrier和CountDownLatch 都位於java.util.concurrent這個包下,其工作原理的核心要點:

☕【Java深層系列】「併發程式設計系列」讓我們一起探索一下CyclicBarrier的技術原理和原始碼分析

CyclicBarrier工作原理分析

那麼接下來給大家分享分析一下JDK1.8的CyclicBarrier的工作原理。

簡單認識CyclicBarrier

何為CyclicBarrier?

  1. CyclicBarrier從英文字面上理解,迴圈柵欄,咋一看好像跟同步器沒多大關係,而柵欄式一排排的阻攔著,好像也有點同步等待的意思;

  2. CyclicBarrier是也一種同步幫助工具,允許多個執行緒相互等待,即多個執行緒到達同步點時被阻塞,直到最後一個執行緒到達同步點時柵欄才會被開啟;

  3. CyclicBarrier內部沒有所謂的公平鎖\非公平鎖的靜態內部類,只是利用了ReentrantLock(獨佔鎖)、ConditionObject(條件物件)實現了執行緒之間相互等待的功能;

CyclicBarrier的state關鍵詞

  1. CyclicBarrier這個類沒有真正的state關鍵詞,它只有parties執行緒總數量,count還沒有進入阻塞的執行緒數量;

  2. CyclicBarrier的實現是間接利用了ReentrantLock(獨佔鎖)的父類AQS的state變數值;

  3. CountDownLatch,A、B、C組執行緒同時執行,A先執行完的話就在那裡等著,等所有A、B、C執行緒中執行最久的執行緒執行完了才開始執行各自的事件;

常用重要的方法


 // 建立給定數值的柵欄總數,也就是支援參與執行緒的最多數值
public CyclicBarrier(int parties)

// 建立給定數值的柵欄總數,也就是支援參與執行緒的最多數值,且當最後一個執行緒執行完時會回撥barrierAction方法
public CyclicBarrier(int parties, Runnable barrierAction)

// 更新換代,改朝換代,觸發喚醒所有在Lock物件上等待的執行緒,釋放所有正在處於阻塞的執行緒
private void nextGeneration()

// 打破平衡,並設定打破平衡的標誌,然後再喚醒所有被阻塞的執行緒,
private void breakBarrier() 

// 導致當前執行緒阻塞,直到其他執行緒呼叫trip.signal()或trip.signalAll()方法喚醒該執行緒
public int await()

// 比await()多了兩個引數,意思就是阻塞等待訊號量的最大時長,等待的時間值為timeout,單位為unit;
public int await(long timeout, TimeUnit unit)

// 阻塞等待的核心方法,如果不需要超時等待訊號量的話則nanos引數是沒用的,否則就有用
private int dowait(boolean timed, long nanos)

// 執行緒之間的等待,這樣一個等待的平衡體系是否被打破
public boolean isBroken() 

// 重置為初始狀態值,就像初始建立CyclicBarrier該例項物件一樣,乾乾淨淨的初始狀態值
public void reset()

// 獲取目前正在處於阻塞狀態的執行緒數量值
public int getNumberWaiting()

// 獲取執行緒數量,也就是柵欄數量總數值
public int getParties()

設計與實現虛擬碼

等待被釋放:

    public int await() throws InterruptedException, BrokenBarrierException {
        try {
            return dowait(false, 0L);
        } catch (TimeoutException toe) {
            throw new Error(toe); // cannot happen
        }
    }

阻塞等待的核心方法;

  • 內部會呼叫trip.await()方法進入Condition等待阻塞佇列;
  • 一旦柵欄數量為零時則會逐個逐個將Condition等待的佇列轉移到CLH的等待阻塞佇列;
  • 所有執行緒被喚醒後然後等待dowait方法內部lock.unlock()一個個釋放執行緒等待;
  • 阻塞的最後一個執行緒還有機會執行構造方法傳入的介面回撥;

CyclicBarrier生活細節化理解

比如百米賽跑,我就以賽跑為例生活化闡述該CyclicBarrier原理,場景:百米賽跑十人蔘賽,終點處有一個裁判計數;

  • 開跑一聲槍響,十個人爭先恐後的向終點跑去,真的是振奮多秒,令人振奮;

  • 當一個人到達終點,這個人就完成了他的賽跑事情了,就沒事一邊玩去了,那麼裁判則減去一個人;

  • 隨著人員陸陸續續的都跑到了終點,最後裁判計數顯示還有0個人未到達,意思就是人員都達到了;

  • 然後裁判就拿著登記的成績屁顛屁顛去輸入電腦登記了;

  • 到此打止,這一系列的動作認為是A組執行緒等待另外其他組執行緒的操作,直到計數器為零,那麼A則再幹其他事情;

原始碼分析CyclicBarrier

CyclicBarrier構造器

構造器原始碼

建立一個給定數值的柵欄總數,也就是支援參與執行緒的最多數值,但是構造方法二還可以通過傳入介面回撥,當最後一個阻塞的執行緒被釋放後,它將有機會執行這個被傳入的回撥介面barrierAction;

    /**
     * Creates a new {@code CyclicBarrier} that will trip when the
     * given number of parties (threads) are waiting upon it, and
     * does not perform a predefined action when the barrier is tripped.
     *
     * @param parties the number of threads that must invoke {@link #await}
     *        before the barrier is tripped
     * @throws IllegalArgumentException if {@code parties} is less than 1
     */
    public CyclicBarrier(int parties) {
        this(parties, null);
    }
    /**
     * Creates a new {@code CyclicBarrier} that will trip when the
     * given number of parties (threads) are waiting upon it, and which
     * will execute the given barrier action when the barrier is tripped,
     * performed by the last thread entering the barrier.
     *
     * @param parties the number of threads that must invoke {@link #await}
     *        before the barrier is tripped
     * @param barrierAction the command to execute when the barrier is
     *        tripped, or {@code null} if there is no action
     * @throws IllegalArgumentException if {@code parties} is less than 1
     */
    public CyclicBarrier(int parties, Runnable barrierAction) {
        if (parties <= 0) throw new IllegalArgumentException();
        this.parties = parties;
        this.count = parties;
        this.barrierCommand = barrierAction;
    }

await()

  • 阻塞等待的核心方法,內部會呼叫trip.await()方法進入Condition等待阻塞佇列,一旦柵欄數量為零時則會逐個逐個將Condition等待的佇列轉移到CLH的等待阻塞佇列;

  • 所有執行緒被喚醒後然後等待dowait方法內部lock.unlock()一個個釋放執行緒等待,阻塞的最後一個執行緒還有機會執行構造方法傳入的介面回撥;

    /**
     * Waits until all {@linkplain #getParties parties} have invoked
     * {@code await} on this barrier.
     *
     * <p>If the current thread is not the last to arrive then it is
     * disabled for thread scheduling purposes and lies dormant until
     * one of the following things happens:
     * <ul>
     * <li>The last thread arrives; or
     * <li>Some other thread {@linkplain Thread#interrupt interrupts}
     * the current thread; or
     * <li>Some other thread {@linkplain Thread#interrupt interrupts}
     * one of the other waiting threads; or
     * <li>Some other thread times out while waiting for barrier; or
     * <li>Some other thread invokes {@link #reset} on this barrier.
     * </ul>
     *
     * <p>If the current thread:
     * <ul>
     * <li>has its interrupted status set on entry to this method; or
     * <li>is {@linkplain Thread#interrupt interrupted} while waiting
     * </ul>
     * then {@link InterruptedException} is thrown and the current thread's
     * interrupted status is cleared.
     *
     * <p>If the barrier is {@link #reset} while any thread is waiting,
     * or if the barrier {@linkplain #isBroken is broken} when
     * {@code await} is invoked, or while any thread is waiting, then
     * {@link BrokenBarrierException} is thrown.
     *
     * <p>If any thread is {@linkplain Thread#interrupt interrupted} while waiting,
     * then all other waiting threads will throw
     * {@link BrokenBarrierException} and the barrier is placed in the broken
     * state.
     *
     * <p>If the current thread is the last thread to arrive, and a
     * non-null barrier action was supplied in the constructor, then the
     * current thread runs the action before allowing the other threads to
     * continue.
     * If an exception occurs during the barrier action then that exception
     * will be propagated in the current thread and the barrier is placed in
     * the broken state.
     *
     * @return the arrival index of the current thread, where index
     *         {@code getParties() - 1} indicates the first
     *         to arrive and zero indicates the last to arrive
     * @throws InterruptedException if the current thread was interrupted
     *         while waiting
     * @throws BrokenBarrierException if <em>another</em> thread was
     *         interrupted or timed out while the current thread was
     *         waiting, or the barrier was reset, or the barrier was
     *         broken when {@code await} was called, or the barrier
     *         action (if present) failed due to an exception
     */
    public int await() throws InterruptedException, BrokenBarrierException {
        try {
            return dowait(false, 0L); // 阻塞的核心方法,重心再次,通過ReentrantLock和Condition組合完成阻塞等待
        } catch (TimeoutException toe) {
            throw new Error(toe); // cannot happen
        }
    }

dowait(false, 0L); // 阻塞的核心方法,重新再次,通過ReentrantLock和Condition組合完成阻塞等待

3.3、dowait(boolean, long)

  • dowait方法是CyclicBarrier實現阻塞等待的核心方法,當await方法被呼叫時阻塞等待被Condition的一個佇列維護著;
  • 然而執行緒從await跳出來時,正常情況下一般都是由於傳送了訊號量,阻塞被解除,那麼Condition的等待佇列將會被轉移至AQS的等待佇列;
  • 然後一個逐漸鎖釋放,最後CyclicBarrier也處於了初始值狀態,供下次呼叫使用;
  • 因此CyclicBarrier每用完一套整個流程,又會回到初始狀態值,又可以被其他地方當做新建立的物件一樣來使用,所以才成為迴圈柵欄;
    /**
     * Main barrier code, covering the various policies.
     */
    private int dowait(boolean timed, long nanos)
        throws InterruptedException, BrokenBarrierException,
               TimeoutException {
        final ReentrantLock lock = this.lock; // 獲取獨佔鎖
        lock.lock(); // 通過lock其父類AQS的CLH佇列阻塞在此,但是為啥又會繼續往下進入臨界區執行try方法,其原因就是trip.await()這句程式碼
        try {
            final Generation g = generation;

            if (g.broken) // 若平衡被一旦打破,則其他所有的執行緒都會丟擲異常,因為即使這裡沒遇到拋異常,下面還會有 if (g.broken) 判斷
                throw new BrokenBarrierException();

            if (Thread.interrupted()) { // 檢測執行緒是否在其他地方被中斷過,若任何一個執行緒被中斷過
                breakBarrier(); // 那麼則打破平衡,並設定打破平衡的標誌,還原初始狀態值,然後再喚醒所有被阻塞的執行緒,
                throw new InterruptedException();
            }

            int index = --count; // 執行一個則減1操作,正常情況下count表示還有多少個未進入臨界區,即還在lock阻塞佇列中
            if (index == 0) {  // tripped 當count值降為0後,則表明所有執行緒都執行完了,那麼就可以happy的一起改朝換代去做其他事情了
                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()進入阻塞等待
                        trip.await(); // 正常情況下,程式碼執行到此就不動了,該方法內部已經呼叫了park方法導致執行緒阻塞等待
                    else if (nanos > 0L)
                        nanos = trip.awaitNanos(nanos); // 在指定時間內等待訊號量
                } catch (InterruptedException ie) { // 若在阻塞等待期間由於被中斷了
                    if (g == generation && ! g.broken) { // 如果還沒改朝換代,並且平衡標誌位還為false的話,則繼續打破平衡並且丟擲中斷異常
                        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) // 這裡也有 if (g.broken) 判斷,若平衡被一旦打破,則其他所有的執行緒都會丟擲異常
                    throw new BrokenBarrierException();

                if (g != generation) // 若已經被改朝換代了,那麼則直接返回index值
                    return index;

                if (timed && nanos <= 0L) { // 若設定了超時標誌,並且不管是傳入的nanos值也好還是通過等待後返回的nanos也好,只要小於或等於零都會打破平衡
                    breakBarrier();
                    throw new TimeoutException();
                }
            }
        } finally {
            lock.unlock(); // 釋放lock鎖
        }
    }

breakBarrier()

打破平衡,並設定打破平衡的標誌,然後再喚醒所有被阻塞的執行緒;

    /**
     * Sets current barrier generation as broken and wakes up everyone.
     * Called only while holding lock.
     */
    private void breakBarrier() {
        generation.broken = true; // 設定打破平衡的標誌
        count = parties; // 重新還原count為初始值
        trip.signalAll(); // 傳送訊號量,喚醒所有Condition中的等待佇列
    }

nextGeneration()

喚醒所有在Condition中等待的佇列,然後還原初始狀態值,並且重新換掉generation的引用,改朝換代,為下一輪操作做準備;

/**
     * Updates state on barrier trip and wakes up everyone.
     * Called only while holding lock.
     */
    private void nextGeneration() {
        // signal completion of last generation
        trip.signalAll();
        // set up next generation
        count = parties;
        generation = new Generation();
    }

AQS的await()

CyclicBarrier的成員屬性 trip( Condition型別 ) 物件的方法:

  1. 該AQS的await方法,因為該方法涉及到為什麼用了獨佔鎖lock.lock之後,dowait方法裡面通過呼叫了trip.await()進行阻塞的話,第二個、第三個執行緒怎麼還會通過lock.lock呼叫之後還能進入臨界區呢。
  2. AQS的方法會呼叫fullyRelease(node)釋放當前執行緒佔有的鎖,所以lock.lock才不至於一直被阻塞在那裡;
  3. 並且Condition也維護了自己的一個連結串列,凡是通過呼叫trip.await()方法的執行緒,都會首先進入Condition的佇列,然後釋放獨佔鎖,想辦法呼叫park方法鎖住當前執行緒;
  4. 然後在被訊號量通知的時候,又會將Condition佇列的結點轉移到AQS的同步佇列中,然後等待呼叫unlock逐個釋放鎖;
	/**
	 * Implements interruptible condition wait.
	 * <ol>
	 * <li> If current thread is interrupted, throw InterruptedException.
	 * <li> Save lock state returned by {@link #getState}.
	 * <li> Invoke {@link #release} with saved state as argument,
	 *      throwing IllegalMonitorStateException if it fails.
	 * <li> Block until signalled or interrupted.
	 * <li> Reacquire by invoking specialized version of
	 *      {@link #acquire} with saved state as argument.
	 * <li> If interrupted while blocked in step 4, throw InterruptedException.
	 * </ol>
	 */
	public final void await() throws InterruptedException {
		if (Thread.interrupted())
			throw new InterruptedException();
		Node node = addConditionWaiter(); // 將當前執行緒包裝一下,然後新增到Condition自己維護的連結串列佇列中
		int savedState = fullyRelease(node); // 釋放當前執行緒佔有的鎖,如果不釋放的話,那麼在第二次呼叫lock.lock()的地方;
		// 如果第一個沒執行完的話,那麼則會一直阻塞等待,那麼也就無法完成柵欄的功能了。
		int interruptMode = 0;
		while (!isOnSyncQueue(node)) { // 是否在AQS的佇列中
			LockSupport.park(this); // 如果不在AQS佇列中的話,則阻塞等待,這裡才是最最最核心阻塞的地方
			if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
				break;
		}
		// 如果在AQS佇列中的話,那麼則考慮重入鎖,重新競爭鎖,重新休息
		if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
			interruptMode = REINTERRUPT;
		if (node.nextWaiter != null) // clean up if cancelled
			unlinkCancelledWaiters();
		if (interruptMode != 0)
			reportInterruptAfterWait(interruptMode);
	}

CyclicBarrier的實戰用法

CyclicBarrier提供2個構造器:

public CyclicBarrier(int parties, Runnable barrierAction) {}
public CyclicBarrier(int parties) {}
  • parties:指讓多少個執行緒或者任務等待至barrier狀態;
  • barrierAction:當這些執行緒都達到barrier狀態時會執行的內容。

CyclicBarrier中最重要的方法就是await方法

//掛起當前執行緒,直至所有執行緒都到達barrier狀態再同時執行後續任務;
public int await() throws InterruptedException, BrokenBarrierException { };

//讓這些執行緒等待至一定的時間,如果還有執行緒沒有到達barrier狀態就直接讓到達barrier的執行緒執行後續任務
public int await(long timeout, TimeUnit unit)throws InterruptedException,BrokenBarrierException,TimeoutException { };
public class cyclicBarrierTest {
    public static void main(String[] args) throws InterruptedException {
        CyclicBarrier cyclicBarrier = new CyclicBarrier(5, new Runnable() {
            @Override
            public void run() {
                System.out.println("執行緒組執行結束");
            }
        });
        for (int i = 0; i < 5; i++) {
            new Thread(new readNum(i,cyclicBarrier)).start();
        }
    }
    static class readNum  implements Runnable{
        private int id;
        private CyclicBarrier cyc;
        public readNum(int id,CyclicBarrier cyc){
            this.id = id;
            this.cyc = cyc;
        }
        @Override
        public void run() {
            synchronized (this){
                System.out.println("id:"+id);
                try {
                    cyc.await();
                    System.out.println("執行緒組任務" + id + "結束,其他任務繼續");
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        }
    }
}

輸出結果:

id:1
id:2
id:4
id:0
id:3
執行緒組執行結束
執行緒組任務3結束,其他任務繼續
執行緒組任務1結束,其他任務繼續
執行緒組任務4結束,其他任務繼續
執行緒組任務0結束,其他任務繼續
執行緒組任務2結束,其他任務繼續

總結

  1. 有了分析CountDownLatch、Semaphore的基礎後,再來分析CyclicBarrier顯然有了紮實的功底,分析起來順手多了;
  2. 在這裡我簡要總結一下CyclicBarrier的流程的一些特性:
    • 用途讓一組執行緒互相等待,直到都到達公共屏障點才開始各自繼續做各自的工作;
    • 可重複利用,每正常走完一次流程,或者異常結束流程,那麼接下來一輪還是可以繼續利用CyclicBarrier實現執行緒等待功能;
    • 共存亡,只要有一個執行緒有異常發生中斷,那麼其它執行緒都會被喚醒繼續工作,然後接著就是拋異常處理;