CountDownLatch

這是什么？先從一段代碼開(kāi)始：

public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            int finalI = i+1;
            new Thread(()->{
                System.out.println("線(xiàn)程："+ finalI +"開(kāi)始執(zhí)行");
            }).start();
        }
    }

你說(shuō)這段代碼中，這個(gè)10個(gè)線(xiàn)程是按照順序執(zhí)行的嗎？看運(yùn)行結(jié)果：

OK，看到結(jié)果之后你就需要明白如下道理：

??在主線(xiàn)程中，for循環(huán)會(huì)創(chuàng)建并啟動(dòng)10個(gè)線(xiàn)程，但是需要注意的是，并不是線(xiàn)程創(chuàng)建且啟動(dòng)之后就會(huì)立馬執(zhí)行線(xiàn)程中的任務(wù)然后再去創(chuàng)建啟動(dòng)下一個(gè)線(xiàn)程，而是所有的線(xiàn)程創(chuàng)建啟動(dòng)之后會(huì)加入一個(gè)線(xiàn)程規(guī)劃器中由操作系統(tǒng)去決定哪個(gè)線(xiàn)程先執(zhí)行任務(wù)，這個(gè)分配是隨機(jī)的，也就是線(xiàn)程執(zhí)行是亂序的，不是順序的！

然后我們?cè)倏矗?/span>

這里的主線(xiàn)程任務(wù)可不是一定在線(xiàn)程執(zhí)行完之后才會(huì)執(zhí)行：

那如果我們有這樣的一個(gè)場(chǎng)景，就是需要所有的線(xiàn)程任務(wù)執(zhí)行完畢之后才能去執(zhí)行主線(xiàn)程任務(wù)，那這個(gè)該怎么辦呢？

這就需要用到我們的CountDownLatch，怎么用呢？很簡(jiǎn)單，看代碼：

然后我們看下代碼：

達(dá)到我們想要的結(jié)果了，是不是很簡(jiǎn)單？

Cyclicbarrier

對(duì)于CountDownLatch來(lái)說(shuō)，大概就是只有計(jì)數(shù)為0才會(huì)觸發(fā)某個(gè)時(shí)間，也就是一個(gè)倒計(jì)時(shí)的效果，而這個(gè)Cyclicbarrier恰好是和CountDownLatch相反的，它是需要從0開(kāi)始計(jì)數(shù)，達(dá)到某個(gè)值才去觸發(fā)某個(gè)時(shí)間，通常叫做回環(huán)柵欄，看下面的例子就能秒懂：

看下運(yùn)行結(jié)果：

這個(gè)還是很好理解的！

semaphore

咋一看，這個(gè)看起來(lái)很陌生，是什么呢？一般叫做信號(hào)量，通過(guò)一個(gè)示例來(lái)快速了解！

這個(gè)例子沒(méi)什么難度吧，我們開(kāi)啟5個(gè)線(xiàn)程來(lái)模擬小孩玩手機(jī)的現(xiàn)象，我們運(yùn)行看下：

這說(shuō)明5個(gè)小孩都搶到手機(jī)，都有手機(jī)玩，那這里的前提就是，最少得有5個(gè)手機(jī)，不然5個(gè)人不夠搶啊，但是現(xiàn)在加入我就只有兩個(gè)手機(jī)咋辦？

是不是就得看他們自己了，誰(shuí)搶到誰(shuí)玩，因?yàn)橹挥?個(gè)手機(jī)，但是有5個(gè)人，那么肯定是2個(gè)人搶到了在玩，而另外3個(gè)人要等待，一旦其中的一個(gè)人玩手機(jī)時(shí)間到放下手機(jī)后，其余的三個(gè)人又會(huì)去搶?zhuān)钡阶詈?，每個(gè)人都玩手機(jī)了！

那面對(duì)這樣的一個(gè)情景，想一下我們?cè)撛趺醋觯?個(gè)人去搶2個(gè)手機(jī)，一旦2個(gè)手機(jī)被搶到，其余的人只能等待，說(shuō)的專(zhuān)業(yè)點(diǎn)，這樣是不是并發(fā)線(xiàn)程數(shù)被控制了，這里控制了只有2個(gè)線(xiàn)程可以同時(shí)去執(zhí)行，其他的必須等待這兩個(gè)線(xiàn)程執(zhí)行完畢才可以執(zhí)行，那看看該怎么做：

這里大家可以類(lèi)比小孩子玩手機(jī)的舉例說(shuō)明！

這里需要注意的是，我們是通過(guò)semaphore來(lái)控制線(xiàn)程并發(fā)數(shù)，其中使用semaphore.acquire();來(lái)記錄進(jìn)來(lái)的線(xiàn)程，執(zhí)行一次相當(dāng)于加1，一旦達(dá)到設(shè)定的線(xiàn)程并發(fā)數(shù)就會(huì)禁止其他線(xiàn)程進(jìn)入，任務(wù)執(zhí)行完畢使用semaphore.release();來(lái)減1，相當(dāng)于釋放資源，其他線(xiàn)程可以進(jìn)入執(zhí)行！

所以啊，任務(wù)執(zhí)行邏輯是放在他們兩者之間的：

ReadWriteLock

這是啥，有了Lock為什么還要有個(gè)ReadWriteLock？我們看下之前Lock加鎖的形式：

我們?cè)趯?xiě)資源的操作上加上了ReentrantLock，這個(gè)時(shí)候可以避免多個(gè)線(xiàn)程對(duì)該資源進(jìn)行寫(xiě)操作，同一時(shí)間只允許一個(gè)線(xiàn)程來(lái)進(jìn)行寫(xiě)操作，但是此時(shí)有什么問(wèn)題呢？

看我們的讀資源操作，此時(shí)是可以有多個(gè)線(xiàn)程進(jìn)行讀操作的，這其實(shí)也不是我們想要的，為什么？

因?yàn)槿绻藭r(shí)有一個(gè)線(xiàn)程正在進(jìn)行寫(xiě)操作，我是不希望其他線(xiàn)程進(jìn)行讀操作的，因?yàn)檫@個(gè)線(xiàn)程很可能讀到舊數(shù)據(jù)，由于多線(xiàn)程執(zhí)行是亂序的，所以很有可能數(shù)據(jù)還沒(méi)有真正寫(xiě)入就被另一個(gè)線(xiàn)程讀取了，雖然我們的map使用了volatile關(guān)鍵字，不過(guò)volatile也就是保證線(xiàn)程緩存中的資源實(shí)時(shí)同步到共享資源，但是如果我這個(gè)線(xiàn)程就沒(méi)有開(kāi)始真正的寫(xiě)，那線(xiàn)程本地緩存中就沒(méi)有最新的數(shù)據(jù)，那你其他線(xiàn)程讀取的自然不是最新的數(shù)據(jù)了！

你可能想到了給讀操作也加上鎖，像這樣：

但是加上鎖之后還是允許一個(gè)線(xiàn)程來(lái)進(jìn)行讀取資源，問(wèn)題并沒(méi)有解決啊，而且有的時(shí)候我還需要在沒(méi)有線(xiàn)程進(jìn)行寫(xiě)操作的時(shí)候，可以有多個(gè)線(xiàn)程進(jìn)行讀操作來(lái)增加效率，顯然，上述做法是不滿(mǎn)足要求的！

這個(gè)時(shí)候就需要我們的ReadWriteLock了，表面意思理解是讀寫(xiě)鎖，它主要可以保證數(shù)據(jù)的一致性，有如下特性：

1. 支持讀-讀共存

2. 不支持讀-寫(xiě)共存

3. 更不支持寫(xiě)-寫(xiě)共存

很明顯的一點(diǎn)，只要有寫(xiě)操作存在，就不允許其他線(xiàn)程進(jìn)行讀或者寫(xiě)！

我們先來(lái)看下之前資源類(lèi)被多線(xiàn)程執(zhí)行的情況，先看不加鎖的情況，同時(shí)對(duì)代碼稍作修改：

然后分別創(chuàng)建5個(gè)線(xiàn)程進(jìn)行寫(xiě)操作，5個(gè)線(xiàn)程進(jìn)行讀操作：

然后我們運(yùn)行程序看看：

可以看到如此一來(lái)執(zhí)行的結(jié)果很亂，在線(xiàn)程1執(zhí)行寫(xiě)操作的時(shí)候還沒(méi)有完成就沒(méi)線(xiàn)程3給打斷了，我們希望的是數(shù)據(jù)一致性得到保障，線(xiàn)程1的寫(xiě)操作完全成功了才允許其他線(xiàn)程繼續(xù)寫(xiě)，而且假如我們模擬線(xiàn)程寫(xiě)數(shù)據(jù)的耗時(shí)操作：

我們?cè)谶\(yùn)行看看：

這就是因?yàn)椋覕?shù)據(jù)還沒(méi)有真正的寫(xiě)入成功就被其他線(xiàn)程讀取，那結(jié)果肯定有誤，怎們辦，我們看下加鎖的情況：

先對(duì)寫(xiě)操作加鎖，看下運(yùn)行情況：

這里一定要注意思考，不然很容易暈……好吧，為了大家更好的理解，我把程序改寫(xiě)一下，你會(huì)理解的更加透徹，首先修改資源類(lèi)：

主要是這些改變，使得打印信息在加鎖情況下更加直觀，然后是我們的操作邏輯：

增加線(xiàn)程名稱(chēng)命名，然后我們?cè)倏闯绦蜻\(yùn)行結(jié)果：

這樣看是不是就直觀了很多，同一個(gè)時(shí)間內(nèi)只能有一個(gè)線(xiàn)程進(jìn)行讀寫(xiě)操作，而且在線(xiàn)程進(jìn)行寫(xiě)操作的時(shí)候，其他線(xiàn)程是無(wú)法進(jìn)行讀寫(xiě)操作的，但是這里也有個(gè)問(wèn)題，就是如果我沒(méi)有寫(xiě)操作在進(jìn)行的時(shí)候，我想進(jìn)行讀操作，但是因?yàn)榧渔i，我只能一個(gè)線(xiàn)程進(jìn)行讀取，其實(shí)此時(shí)數(shù)據(jù)沒(méi)有被其他線(xiàn)程進(jìn)行寫(xiě)操作，我完全可以多個(gè)線(xiàn)程進(jìn)行同時(shí)讀取，這樣效率更高，但是很顯然通過(guò)Lock的形式是無(wú)法滿(mǎn)足的！

這個(gè)時(shí)候就到我們的ReadWriteLock閃亮登場(chǎng)了！

這里需要再回顧下它的主要特性：

1. 支持讀-讀共存

2. 不支持讀-寫(xiě)共存

3. 更不支持寫(xiě)-寫(xiě)共存

對(duì)于讀-寫(xiě)和寫(xiě)-寫(xiě)我們發(fā)現(xiàn)使用Lock也是可以實(shí)現(xiàn)的，但是它無(wú)法完成讀-讀共存的情況，我們看看下：

我們?cè)谧x操作中模擬耗時(shí)操作，然后我們只運(yùn)行多線(xiàn)程執(zhí)行讀操作的演示，結(jié)果如下：

實(shí)際運(yùn)行就會(huì)發(fā)現(xiàn)，會(huì)花費(fèi)5秒來(lái)執(zhí)行完程序，因?yàn)槊總€(gè)線(xiàn)程執(zhí)行讀操作需要1秒，因?yàn)榧渔i是單線(xiàn)程執(zhí)行，所以需要五秒，我們看下使用ReadWriteLock的情況：

這里一定要注意ReadWriteLock的用法，同Lock一樣，它是個(gè)接口，需要使用其子類(lèi)ReentrantReadWriteLock，同時(shí)為了區(qū)分讀寫(xiě)鎖，搞了一下形式：

//寫(xiě)鎖
lock.writeLock()
//讀鎖
lock.readLock()

然后我們看使用了ReentrantReadWriteLock之后的讀操作情況：

可以看到，即使你加鎖了，但是對(duì)于讀操作，是允許并發(fā)執(zhí)行的，相當(dāng)于之前是需要5秒，使用ReentrantReadWriteLock之后只需要1秒，效率大大提高！

所以對(duì)于ReentrantReadWriteLock來(lái)說(shuō)記住其三個(gè)特性：

1. 支持讀-讀共存

2. 不支持讀-寫(xiě)共存

3. 更不支持寫(xiě)-寫(xiě)共存

那么，你學(xué)會(huì)了嗎？