Java併發包5--同步工具CountDownLatch、CyclicBarrier、Semaphore的實現原理解析

前言：

JUC中提供了很多同步工具類，比如CountDownLatch、CyclicBarrier、Semaphore等，都可以作用同步手段來實現多執行緒之間的同步效果

一、CountDownLatch

1.1、CountDownLatch的使用

CountDownLatch可以理解為是同步計數器，作用是允許一個或多個執行緒等待其他執行緒執行完成之後才繼續執行，比如打dota、LoL或者王者榮耀時，建立了一個五人房，只有當五個玩家都準備了之後，遊戲才能正式開始，否則遊戲主執行緒會一直等待著直到玩家全部準備。在玩家沒準備之前，遊戲主執行緒會一直處於等待狀態。如果把CountDownLatch比做此場景都話，相當於開始定義了匹配遊戲需要5個執行緒，只有當5個執行緒都準備完成了之後，主執行緒才會開始進行匹配操作。

CountDownLatch案例如下：

public static void countDownLatchTest() throws Exception{
        CountDownLatch latch = new CountDownLatch(5);//定義了需要達到條件都執行緒為5個執行緒
        new Thread(new Runnable() {
            @Override
            public void run() {
                for (int i=0; i<12; i++){
                    try {
                        Thread.sleep(1000L);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    new Thread(new Runnable() {
                        @Override
                        public void run() {
                            long count = latch.getCount();
                            latch.countDown();/**相當於準備遊戲成功*/
                            if(count > 0) {
                                System.out.println("執行緒" + Thread.currentThread().getName() + "組隊準備,還需等待" + latch.getCount() + "人準備");
                            }else {
                                System.out.println("執行緒" + Thread.currentThread().getName() + "組隊準備,房間已滿不可加入");
                            }
                        }
                    }).start();
                }
            }
        }).start();
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    System.out.println("遊戲房間等待玩家加入...");
                    /**一直等待到規定數量到執行緒都完全準備之後才會繼續往下執行*/
                    latch.await();
                    System.out.println("遊戲房間已鎖定...");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
        System.out.println("等待玩家準備中...");
        /**一直等待到規定數量到執行緒都完全準備之後才會繼續往下執行*/
        latch.await();
        System.out.println("遊戲匹配中...");
    }

 

 

執行結果如下：

等待玩家準備中...
遊戲房間等待玩家加入...
執行緒Thread-2組隊準備,還需等待4人準備
執行緒Thread-3組隊準備,還需等待3人準備
執行緒Thread-4組隊準備,還需等待2人準備
執行緒Thread-5組隊準備,還需等待1人準備
執行緒Thread-6組隊準備,還需等待0人準備
遊戲匹配中...
遊戲房間已鎖定...
執行緒Thread-7組隊準備,房間已滿不可加入
執行緒Thread-8組隊準備,房間已滿不可加入
執行緒Thread-9組隊準備,房間已滿不可加入
執行緒Thread-10組隊準備,房間已滿不可加入
執行緒Thread-11組隊準備,房間已滿不可加入
執行緒Thread-12組隊準備,房間已滿不可加入
執行緒Thread-13組隊準備,房間已滿不可加入

 

本案例中有兩個執行緒都呼叫了latch.await()方法，則這兩個執行緒都會被阻塞，直到條件達成。當5個執行緒呼叫countDown方法之後，達到了計數器的要求，則後續再執行countDown方法的效果就無效了，因為CountDownLatch僅一次有效。

1.2、CountDownLatch的實現原理

CountDownLatch的實現原理主要是通過內部類Sync來實現的，內部類Sync是AQS的子類，主要是通過重寫AQS的共享式獲取和釋放同步狀態方法來實現的。原始碼如下：

CountDownLatch初始化時需要定義呼叫count的次數，然後每呼叫一次countDown方法都會計數減一，原始碼如下：

public CountDownLatch(int count) {
        if (count < 0) throw new IllegalArgumentException("count < 0");
        this.sync = new Sync(count);
    }

 

public void countDown() {
        sync.releaseShared(1);
    }

 

public void await() throws InterruptedException {
        sync.acquireSharedInterruptibly(1);
    }

 

可以看出CountDownLatch的實現邏輯全部都是呼叫內部類Sync的對應方法實現的，Sync原始碼如下：

private static final class Sync extends AbstractQueuedSynchronizer {
        private static final long serialVersionUID = 4982264981922014374L;

        Sync(int count) {
            /**初始化設定計數值實際就是設定AQS的同步狀態值*/
            setState(count);
        }

        int getCount() {
            return getState();
        }

        protected int tryAcquireShared(int acquires) {
            return (getState() == 0) ? 1 : -1;
        }

        /**CountDownLatch的countDown方法的實際執行邏輯*/
        protected boolean tryReleaseShared(int releases) {
            // Decrement count; signal when transition to zero
            for (;;) {
                int c = getState();
                /**當CountDownLatch的計數值為0時,表示倒計數已完成,則直接返回false*/
                if (c == 0)
                    return false;
                int nextc = c-1;
                /**通過CAS操作來設定同步狀態自減1操作*/
                if (compareAndSetState(c, nextc))
                    /**返回當前同步狀態值是否為0,只有當狀態值為0時才返回true,否則返回false*/
                    return nextc == 0;
            }
        }
    }

 

通過內部類Sync的原始碼可以分析出，CountDownLatch的實現完整邏輯如下：

1、初始化CountDownLatch實際就是設定了AQS的state為計數的值

2、呼叫CountDownLatch的countDown方法時實際就是呼叫AQS的釋放同步狀態的方法，每呼叫一次就自減一次state值

3、呼叫await方法實際就呼叫AQS的共享式獲取同步狀態的方法acquireSharedInterruptibly(1)，這個方法的實現邏輯就呼叫子類Sync的tryAcquireShared方法，只有當子類Sync的tryAcquireShared方法返回大於0的值時才算獲取同步狀態成功，

否則就會一直在死迴圈中不斷重試，直到tryAcquireShared方法返回大於等於0的值，而Sync的tryAcquireShared方法只有當AQS中的state值為0時才會返回1，否則都返回-1，也就相當於只有當AQS的state值為0時，await方法才會執行成功，否則

就會一直處於死迴圈中不斷重試。

總結：

CountDownLatch實際完全依靠AQS的共享式獲取和釋放同步狀態來實現，初始化時定義AQS的state值，每呼叫countDown實際就是釋放一次AQS的共享式同步狀態，await方法實際就是嘗試獲取AQS的同步狀態，只有當同步狀態值為0時才能獲取成功。

二、CyclicBarrier

2.1、CyclicBarrier的使用

CyclicBarrier可以理解為一個迴圈同步屏障，定義一個同步屏障之後，當一組執行緒都全部達到同步屏障之前都會被阻塞，直到最後一個執行緒達到了同步屏障之後才會被開啟，其他執行緒才可繼續執行。

還是以dota、LoL和王者榮耀為例，當第一個玩家準備了之後，還需要等待其他4個玩家都準備，遊戲才可繼續，否則準備的玩家會被一直處於等待狀態，只有當最後一個玩家準備了之後，遊戲才會繼續執行。

CyclicBarrier使用案例如下：

public static void CyclicBarrierTest() throws Exception {
        CyclicBarrier barrier = new CyclicBarrier(5);//定義需要達到同步屏障的執行緒數量
        for (int i=0;i<12;i++){
            Thread.sleep(1000L);
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        System.out.println("執行緒"+Thread.currentThread().getName()+"組隊準備,當前" + (barrier.getNumberWaiting()+1) + "人已準備");
                        barrier.await();/**執行緒進入等待,直到最後一個執行緒達到同步屏障*/
                        System.out.println("執行緒:"+Thread.currentThread().getName()+"開始組隊遊戲");
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    } catch (BrokenBarrierException e) {
                        e.printStackTrace();
                    }
                }
            }).start();
        }
    }

 

執行結果如下：

執行緒Thread-0組隊準備,當前1人已準備
執行緒Thread-1組隊準備,當前2人已準備
執行緒Thread-2組隊準備,當前3人已準備
執行緒Thread-3組隊準備,當前4人已準備
執行緒Thread-4組隊準備,當前5人已準備
執行緒:Thread-4開始組隊遊戲
執行緒:Thread-0開始組隊遊戲
執行緒:Thread-1開始組隊遊戲
執行緒:Thread-2開始組隊遊戲
執行緒:Thread-3開始組隊遊戲
執行緒Thread-5組隊準備,當前1人已準備
執行緒Thread-6組隊準備,當前2人已準備
執行緒Thread-7組隊準備,當前3人已準備
執行緒Thread-8組隊準備,當前4人已準備
執行緒Thread-9組隊準備,當前5人已準備
執行緒:Thread-9開始組隊遊戲
執行緒:Thread-5開始組隊遊戲
執行緒:Thread-7開始組隊遊戲
執行緒:Thread-6開始組隊遊戲
執行緒:Thread-8開始組隊遊戲
執行緒Thread-10組隊準備,當前1人已準備
執行緒Thread-11組隊準備,當前2人已準備

 

本案例中定義了達到同步屏障的執行緒為5個，每當一個執行緒呼叫了barrier.await()方法之後表示該執行緒已達到屏障，此時當前執行緒會被阻塞，只有當最後一個執行緒呼叫了await方法之後，被阻塞的其他執行緒才會被喚醒繼續執行。

另外CyclicBarrier是迴圈同步屏障，同步屏障開啟之後立馬會繼續計數，等待下一組執行緒達到同步屏障。而CountDownLatch僅單次有效。

2.2、CyclicBarrier的實現原理

先看下CyclicBarrier的構造方法

public CyclicBarrier(int parties) {
        this(parties, null);
    }

    public CyclicBarrier(int parties, Runnable barrierAction) {
        if (parties <= 0) throw new IllegalArgumentException();
        this.parties = parties;//同步屏障總需執行緒數
        this.count = parties;//當前剩餘需要達到的執行緒數
        this.barrierCommand = barrierAction;
    }

 

CyclicBarrier的構造方法沒有特殊之處，主要是給兩個屬性parties(匯流排程數)、count(當前剩餘執行緒數)進行賦值，這裡需要兩個值的原因是CyclicBarrier提供了重置的功能，當呼叫reset方法重置時就需要將count值再賦值成parties的值

再看下await方法的實現邏輯

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

    /**
     * Main barrier code, covering the various policies.
     */
    private int dowait(boolean timed, long nanos)
            throws InterruptedException, BrokenBarrierException,
            TimeoutException {
        //CyclicBarrier有個ReentrantLock屬性的lock
        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();
            }
            //count自減操作
            int index = --count;
            //判斷當前還需達到同步屏障的執行緒數是否為0
            if (index == 0) {  // tripped
                boolean ranAction = false;
                try {
                    //barrierCommand是同步屏障開啟之後需要執行的Runnable物件
                    final Runnable command = barrierCommand;
                    if (command != null)
                        //如果Runnable物件不為空直接執行Runnable執行緒任務
                        command.run();
                    ranAction = true;
                    //本次同步屏障全部達成,喚醒所有執行緒並開始下一次同步屏障
                    nextGeneration();
                    return 0;
                } finally {
                    if (!ranAction)
                        breakBarrier();
                }
            }

            // loop until tripped, broken, interrupted, or timed out
            for (;;) {
                try {
                    if (!timed)
                        //呼叫Condition物件的await方法使當前執行緒進入等待狀態
                        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();
        }
    }

    private void nextGeneration() {
        // signal completion of last generation
        //喚醒所有執行緒
        trip.signalAll();
        // set up next generation
        count = parties;
        generation = new Generation();
    }

 從原始碼可以看出CyclicBarrier的實現原理主要是通過ReentrantLock和Condition來實現的，主要實現流程如下：

1、建立CyclicBarrier時定義了CyclicBarrier物件需要達到的執行緒數count

2、每當一個執行緒執行了await方法時，需要先通過ReentrantLock進行加鎖操作，然後對count進行自減操作，操作成功則判斷當前count是否為0；

3、如果當前count不為0則呼叫Condition的await方法使當前執行緒進入等待狀態；

4、如果當前count為0則表示同步屏障已經完全，此時呼叫Condition的signalAll方法喚醒之前所有等待的執行緒，並開啟迴圈的下一次同步屏障功能；

5、喚醒其他執行緒之後，其他執行緒繼續執行剩餘的邏輯。

2.3、通過Synchronized和wait/notify實現CyclicBarrier

通過分析瞭解了CyclicBarrier是通過ReentrantLock和Condition來實現的，而ReentrantLock+Condition在使用上基本上等同於Synchronized+wait/notify，既然如此就可以通過Synchronized+wait/notify來自定義一個CyclicBarrier，話不多說，程式碼如下：

public class MyCyclicBarrier {

    public MyCyclicBarrier(int parties){
        this.parties = parties;
        this.count = parties;
    }

    /**當前剩餘數量*/
    private int count;

    /**設定同數量*/
    private int parties;

    /**獲取當前已準備數量*/
    public int getNumberWaiting(){
        return parties-count;
    }

    public int await(){
        synchronized (this){
            int rest = --count;
            if(rest==0){
                //當剩餘數量為0時表示所有執行緒達到屏障,則重置同步屏障並喚醒所有執行緒
                this.count = parties;
                this.notifyAll();
                return 0;
            }
            try {
                //當剩餘數量大於0時,執行緒進入等待狀態
                this.wait();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        return count;
    }


    /**測試 Main 方法*/
    public static void main(String[] args) throws InterruptedException {
        MyCyclicBarrier barrier = new MyCyclicBarrier(5);//定義需要達到同步屏障的執行緒數量
        for (int i=0;i<12;i++){
            Thread.sleep(1000L);
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        System.out.println("執行緒"+Thread.currentThread().getName()+"組隊準備,當前" + (barrier.getNumberWaiting()+1) + "人已準備");
                        barrier.await();
                        System.out.println("執行緒:"+Thread.currentThread().getName()+"開始組隊遊戲");
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
                }
            }).start();
        }
    }
}

 

執行結果如下：

執行緒Thread-0組隊準備,當前1人已準備
執行緒Thread-1組隊準備,當前2人已準備
執行緒Thread-2組隊準備,當前3人已準備
執行緒Thread-3組隊準備,當前4人已準備
執行緒Thread-4組隊準備,當前5人已準備
執行緒:Thread-4開始組隊遊戲
執行緒:Thread-3開始組隊遊戲
執行緒:Thread-0開始組隊遊戲
執行緒:Thread-1開始組隊遊戲
執行緒:Thread-2開始組隊遊戲
執行緒Thread-5組隊準備,當前1人已準備
執行緒Thread-6組隊準備,當前2人已準備
執行緒Thread-7組隊準備,當前3人已準備
執行緒Thread-8組隊準備,當前4人已準備
執行緒Thread-9組隊準備,當前5人已準備
執行緒:Thread-9開始組隊遊戲
執行緒:Thread-7開始組隊遊戲
執行緒:Thread-5開始組隊遊戲
執行緒:Thread-6開始組隊遊戲
執行緒:Thread-8開始組隊遊戲
執行緒Thread-10組隊準備,當前1人已準備
執行緒Thread-11組隊準備,當前2人已準備

 

可以看出實現的效果和CyclicBarrier實現的效果完全一樣

三、Semaphore

3.1、Semaphore的使用

Semaphore字面意思是訊號量，實際可以看作是一個限流器，初始化Semaphore時就定義好了最大通行證數量，每次呼叫時呼叫方法來消耗，業務執行完畢則釋放通行證，如果通行證消耗完，再獲取通行證時就需要阻塞執行緒直到有通行證可以獲取。

比如銀行櫃檯的視窗，一共有5個視窗可以使用，當視窗都被佔用時，後面來的人就需要排隊等候，直到有視窗使用者辦理完業務離開之後後面的人才可繼續爭取。模擬程式碼如下：

 public static void semaphoreTest() throws InterruptedException {
        int count = 5;
        Semaphore semaphore = new Semaphore(count);
        System.out.println("初始化" + count + "個銀行櫃檯視窗");
        for (int i=0;i<10;i++){
            Thread.sleep(1000L);
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        System.out.println("使用者"+Thread.currentThread().getName()+"佔用視窗");
                        semaphore.acquire(1);//獲取許可證
                        /**使用者辦理業務需要消耗一定時間*/
                        System.out.println("使用者"+Thread.currentThread().getName()+"開始辦理業務");
                        Thread.sleep(5000L);
                        semaphore.release();//釋放許可證
                        System.out.println("使用者"+Thread.currentThread().getName()+"離開視窗");
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
                }
            }).start();
        }
    }

 

 執行結果如下:

初始化5個銀行櫃檯視窗
使用者Thread-0佔用視窗
使用者Thread-0開始辦理業務
使用者Thread-1佔用視窗
使用者Thread-1開始辦理業務
使用者Thread-2佔用視窗
使用者Thread-2開始辦理業務
使用者Thread-3佔用視窗
使用者Thread-3開始辦理業務
使用者Thread-4佔用視窗
使用者Thread-4開始辦理業務
使用者Thread-0離開視窗
使用者Thread-5佔用視窗
使用者Thread-5開始辦理業務
使用者Thread-1離開視窗
使用者Thread-6佔用視窗
使用者Thread-6開始辦理業務
使用者Thread-2離開視窗
使用者Thread-7佔用視窗
使用者Thread-7開始辦理業務
使用者Thread-3離開視窗
使用者Thread-8佔用視窗
使用者Thread-8開始辦理業務
使用者Thread-4離開視窗
使用者Thread-9佔用視窗
使用者Thread-9開始辦理業務
使用者Thread-5離開視窗
使用者Thread-6離開視窗
使用者Thread-7離開視窗
使用者Thread-8離開視窗
使用者Thread-9離開視窗 

可以看出前5個執行緒可以直接佔用視窗，但是後5個執行緒需要等待前面的執行緒離開了視窗之後才可佔用視窗。

Semaphore呼叫acquire方法獲取許可證，可以同時獲取多個，但是也需要對應的釋放多個，否則會造成其他執行緒獲取不到許可證的情況。一旦許可證被消耗完，那麼執行緒就需要被阻塞，直到許可證被釋放才可繼續執行。

另外Semaphore還具有公平模式和非公平模式兩種用法，公平模式則遵循FIFO原則先排隊的執行緒先拿到許可證；非公平模式則自行爭取。

3.2、Semaphore實現原理

Semaphore的構造方法

public Semaphore(int permits) {
        //非公平模式
        sync = new NonfairSync(permits);
    }

    public Semaphore(int permits, boolean fair) {
        //公平模式
        sync = fair ? new FairSync(permits) : new NonfairSync(permits);
    }

構造方法只有兩個引數，一個是許可證總數量，一個是是否為公平模式；預設是非公平模式

Semaphore的實現全部是通過其內部類Sync來實現了，Sync也是AQS的子類，Semaphore的實現方式基本上和ReentrantLock的實現原理如出一轍。

公平模式實現原理：

FairSync(int permits) {
            //初始化AQS的state的值
            super(permits);
        }

        protected int tryAcquireShared(int acquires) {
            for (;;) {
                //當首節點的後繼節點不是當前執行緒時直接return -1
                if (hasQueuedPredecessors())
                    return -1;
                //獲取當前AQS的state值
                int available = getState();
                //將state減去需要佔用的許可證數量得到剩餘的許可證數量
                int remaining = available - acquires;
                /**
                 * 當remaining<0時返回remaining則表示獲取許可證失敗,會進入AQS的死迴圈不停重試
                 * 當remain>0時,並且CAS成功了則返回remaining,表示獲取許可證成功了
                 * */
                if (remaining < 0 ||
                        compareAndSetState(available, remaining))
                    return remaining;
            }
        }

 

公平模式就是噹噹前執行緒是AQS同步佇列首節點的後繼節點時才有權利嘗試獲取共享式的同步狀態，並將同步狀態值減去需要佔用的許可證數量，如果剩餘許可證數量小於0則表示獲取失敗進入AQS的死迴圈不停重試；

如果許可證數量大於0並且CAS設定成功了，則返回剩餘許可證數量表示搶佔許可證成功；

非公平模式實現原理：

看我公平模式的實現基本是就可以猜到非公平模式是如何實現的，只是會少了一步判斷當前節點是否是首節點的後繼節點而已。

static final class NonfairSync extends Sync {
                private static final long serialVersionUID = -2694183684443567898L;

                NonfairSync(int permits) {
                    super(permits);
                }

                protected int tryAcquireShared(int acquires) {
                    return nonfairTryAcquireShared(acquires);
                }
            }

            final int nonfairTryAcquireShared(int acquires) {
                for (;;) {
                    int available = getState();
                    int remaining = available - acquires;
                    if (remaining < 0 ||
                            compareAndSetState(available, remaining))
                        return remaining;
                }
            }

 

瞭解完Semaphore的公平模式和非公平模式的佔有許可證的方法，再分析釋放許可證的方法，不過可以先自行猜測下會是如何實現的，既然獲取許可證是通過state欄位不斷減少來實現的，那麼毫無疑問釋放許可證就肯定是不斷給state增加來實現的。

釋放許可證原始碼如下：

/**嘗試釋放許可證*/
    protected final boolean tryReleaseShared(int releases) {
        for (;;) {
            int current = getState();
            int next = current + releases;
            if (next < current) // overflow
                throw new Error("Maximum permit count exceeded");
            if (compareAndSetState(current, next))
                return true;
        }
    }

 

Semaphore的釋放許可證實際就是呼叫AQS的共享式釋放同步狀態的方法，然後呼叫內部類Sync重寫的AQS的tryReleaseShared方法，實現邏輯就是不停CAS設定state的值加上需要釋放的數量，直到CAS成功。這裡少了AQS的邏輯解析，有興趣可自行回顧AQS的共享式釋放同步狀態的實現原理。

四、Extra Knowledge

4.1、CountDownLatch 和 CyclicBarrier的區別？

CountDownLatch和CyclicBarrier實現的效果看似都是某個執行緒等待一組執行緒達到條件之後才可繼續執行，但是實際上兩者存在很多區別。

1、CountDownLatch阻塞的是呼叫await()的執行緒，不會阻塞達到條件的執行緒；CyclicBarrier阻塞的是達到同步屏障的所有執行緒

2、CountDownLatch採用倒數計數，定義數量之後，每當一個執行緒達到要求之後就減一；CyclicBarrier是正數計數，當數量達到定義的數量之後就開啟同步屏障

3、CountDownLatch僅單次有效，不可重複使用；CyclicBarrir可以迴圈重複使用

4、CountDownLatch定義的數量和實際執行緒數無關，可以有一個執行緒執行多次countDown()；CyclicBarrier定義的數量和實際執行緒數一致，必須由多個執行緒都達到要求執行才行(執行緒呼叫await()方法之後就會被阻塞，想呼叫多次也不行的)

5、CountDownLatch是通過內部類Sync繼承AQS來實現的；CyclicBarrier是通過重入鎖ReentrantLock來實現的

6、CountDownLatch不可重置；CyclicBarrier可以呼叫reset方法進行重置