【高并發(fā)】高并發(fā)場(chǎng)景下如何優(yōu)化加鎖方式？看完這篇我確實(shí)明白了??！

寫在前面

很多時(shí)候，我們?cè)诓l(fā)編程中，涉及到加鎖操作時(shí)，對(duì)代碼塊的加鎖操作真的合理嗎？還有沒(méi)有需要優(yōu)化的地方呢？

前言

在《【高并發(fā)】?jī)?yōu)化加鎖方式時(shí)竟然死鎖了！！》一文中，我們介紹了產(chǎn)生死鎖時(shí)的四個(gè)必要條件，只有四個(gè)條件同時(shí)具備時(shí)才能發(fā)生死鎖。其中，我們?cè)?strong style="font-size: inherit;color: inherit;line-height: inherit;">阻止請(qǐng)求與保持條件時(shí)，采用了一次性申請(qǐng)所有的資源的方式。例如在我們完成轉(zhuǎn)賬操作的過(guò)程中，我們一次性申請(qǐng)賬戶A和賬戶B，兩個(gè)賬戶都申請(qǐng)成功后，再執(zhí)行轉(zhuǎn)賬的操作。其中，在我們實(shí)現(xiàn)的轉(zhuǎn)賬方法中，使用了死循環(huán)來(lái)循環(huán)獲取資源，直到同時(shí)獲取到賬戶A和賬戶B為止，核心代碼如下所示。

//一次申請(qǐng)轉(zhuǎn)出賬戶和轉(zhuǎn)入賬戶，直到成功
while(!requester.applyResources(this, target)){
    //循環(huán)體為空
    ;
}

如果ResourcesRequester類的applyResources()方法執(zhí)行的時(shí)間非常短，并且程序并發(fā)帶來(lái)的沖突不大，程序循環(huán)幾次到幾十次就可以同時(shí)獲取到轉(zhuǎn)出賬戶和轉(zhuǎn)入賬戶，這種方案就是可行的。

但是，如果ResourcesRequester類的applyResources()方法執(zhí)行的時(shí)間比較長(zhǎng)，或者說(shuō)，程序并發(fā)帶來(lái)的沖突比較大，此時(shí)，可能需要循環(huán)成千上萬(wàn)次才能同時(shí)獲取到轉(zhuǎn)出賬戶和轉(zhuǎn)入賬戶。這樣就太消耗CPU資源了，此時(shí)，這種方案就是不可行的了。

那么，有沒(méi)有什么方式對(duì)這種方案進(jìn)行優(yōu)化呢？

問(wèn)題分析

既然使用死循環(huán)一直獲取資源這種方案存在問(wèn)題，那我們換位思考一下。當(dāng)線程執(zhí)行時(shí)，發(fā)現(xiàn)條件不滿足，是不是可以讓線程進(jìn)入等待狀態(tài)？當(dāng)條件滿足的時(shí)候，通知等待的線程重新執(zhí)行？

也就是說(shuō)，如果線程需要的條件不滿足，我們就讓線程進(jìn)入等待狀態(tài)；如果線程需要的條件滿足時(shí)，我們?cè)偻ㄖ却木€程重新執(zhí)行。這樣，就能夠避免程序進(jìn)行循環(huán)等待進(jìn)而消耗CPU的問(wèn)題。

那么，問(wèn)題又來(lái)了！當(dāng)條件不滿足時(shí)，如何實(shí)現(xiàn)讓線程等待？當(dāng)條件滿足時(shí)，又如何喚醒線程呢？

不錯(cuò)，這是個(gè)問(wèn)題！不過(guò)這個(gè)問(wèn)題解決起來(lái)也非常簡(jiǎn)單。簡(jiǎn)單的說(shuō)，就是使用線程的等待與通知機(jī)制。

線程的等待與通知機(jī)制

我們可以使用線程的等待與通知機(jī)制來(lái)優(yōu)化阻止請(qǐng)求與保持條件時(shí)，循環(huán)獲取賬戶資源的問(wèn)題。具體的等待與通知機(jī)制如下所示。

執(zhí)行的線程首先獲取互斥鎖，如果線程繼續(xù)執(zhí)行時(shí)，需要的條件不滿足，則釋放互斥鎖，并進(jìn)入等待狀態(tài)；當(dāng)線程繼續(xù)執(zhí)行需要的條件滿足時(shí)，就通知等待的線程，重新獲取互斥鎖。

那么，說(shuō)了這么多，Java支持這種線程的等待與通知機(jī)制嗎？其實(shí)，這個(gè)問(wèn)題問(wèn)的就有點(diǎn)廢話了，Java這么優(yōu)秀（牛逼）的語(yǔ)言肯定支持啊，而且實(shí)現(xiàn)起來(lái)也比較簡(jiǎn)單。

用Java實(shí)現(xiàn)線程的等待與通知機(jī)制

實(shí)現(xiàn)方式

其實(shí)，使用Java語(yǔ)言實(shí)現(xiàn)線程的等待與通知機(jī)制有多種方式，這里我就簡(jiǎn)單的列舉一種方式，其他的方式大家可以自行思考和實(shí)現(xiàn)，有不懂的地方也可以問(wèn)我！

在Java語(yǔ)言中，實(shí)現(xiàn)線程的等待與通知機(jī)制，一種簡(jiǎn)單的方式就是使用synchronized并結(jié)合wait()、notify()和notifyAll()方法來(lái)實(shí)現(xiàn)。

實(shí)現(xiàn)原理

我們使用synchronized加鎖時(shí)，只允許一個(gè)線程進(jìn)入synchronized保護(hù)的代碼塊，也就是臨界區(qū)。如果一個(gè)線程進(jìn)入了臨界區(qū)，則其他的線程會(huì)進(jìn)入阻塞隊(duì)列里等待，這個(gè)阻塞隊(duì)列和synchronized互斥鎖是一對(duì)一的關(guān)系，也就是說(shuō)，一把互斥鎖對(duì)應(yīng)著一個(gè)獨(dú)立的阻塞隊(duì)列。

在并發(fā)編程中，如果一個(gè)線程獲得了synchronized互斥鎖，但是不滿足繼續(xù)向下執(zhí)行的條件，則需要進(jìn)入等待狀態(tài)。此時(shí)，可以使用Java中的wait()方法來(lái)實(shí)現(xiàn)。當(dāng)調(diào)用wait()方法后，當(dāng)前線程就會(huì)被阻塞，并且會(huì)進(jìn)入一個(gè)等待隊(duì)列中進(jìn)行等待，這個(gè)由于調(diào)用wait()方法而進(jìn)入的等待隊(duì)列也是互斥鎖的等待隊(duì)列。而且，線程在進(jìn)入等待隊(duì)列的同時(shí)，會(huì)釋放自身獲得的互斥鎖，這樣，其他線程就有機(jī)會(huì)獲得互斥鎖，進(jìn)而進(jìn)入臨界區(qū)了。整個(gè)過(guò)程可以表示成下圖所示。

當(dāng)線程執(zhí)行的條件滿足時(shí)，可以使用Java提供的notify()和notifyAll()方法來(lái)通知互斥鎖等待隊(duì)列中的線程，我們可以使用下圖來(lái)簡(jiǎn)單的表示這個(gè)過(guò)程。

這里，需要注意如下事項(xiàng)：

（1）使用notify()和notifyAll()方法通知線程時(shí)，調(diào)用notify()和notifyAll()方法時(shí)，滿足線程的執(zhí)行條件，但是當(dāng)線程真正執(zhí)行的時(shí)候，條件可能已經(jīng)不再滿足了，可能有其他線程已經(jīng)進(jìn)入臨界區(qū)執(zhí)行。

（2）被通知的線程繼續(xù)執(zhí)行時(shí)，需要先獲取互斥鎖，因?yàn)樵谡{(diào)用wait()方法等待時(shí)已經(jīng)釋放了互斥鎖。

（3）wait()、notify()和notifyAll()方法操作的隊(duì)列是互斥鎖的等待隊(duì)列，如果synchronized鎖定的是this對(duì)象，則一定要使用this.wait()、this.notify()和this.notifyAll()方法；如果synchronized鎖定的是target對(duì)象，則一定要使用target.wait()、target.notify()和target.notifyAll()方法。

（4）wait()、notify()和notifyAll()方法調(diào)用的前提是已經(jīng)獲取了相應(yīng)的互斥鎖，也就是說(shuō)，wait()、notify()和notifyAll()方法都是在synchronized方法中或代碼塊中調(diào)用的。如果在synchronized方法外或代碼塊外調(diào)用了三個(gè)方法，或者鎖定的對(duì)象是this，使用target對(duì)象調(diào)用三個(gè)方法的話，JVM會(huì)拋出java.lang.IllegalMonitorStateException異常。

具體實(shí)現(xiàn)

實(shí)現(xiàn)邏輯

在實(shí)現(xiàn)之前，我們還需要考慮以下幾個(gè)問(wèn)題：

• 選擇哪個(gè)互斥鎖

在之前的程序中，我們?cè)赥ansferAccount類中，存在一個(gè)ResourcesRequester 類的單例對(duì)象，所以，我們是可以使用this作為互斥鎖的。這一點(diǎn)大家需要重點(diǎn)理解。

• 線程執(zhí)行轉(zhuǎn)賬操作的條件

轉(zhuǎn)出賬戶和轉(zhuǎn)入賬戶都沒(méi)有被分配過(guò)。

• 線程什么時(shí)候進(jìn)入等待狀態(tài)

線程繼續(xù)執(zhí)行需要的條件不滿足的時(shí)候，進(jìn)入等待狀態(tài)。

• 什么時(shí)候通知等待的線程執(zhí)行

當(dāng)存在線程釋放賬戶的資源時(shí)，通知等待的線程繼續(xù)執(zhí)行。

綜上，我們可以得出以下核心代碼。

while(不滿足條件){
    wait();
}

那么，問(wèn)題來(lái)了！為何是在while循環(huán)中調(diào)用wait()方法呢？因?yàn)楫?dāng)wait()方法返回時(shí)，有可能線程執(zhí)行的條件已經(jīng)改變，也就是說(shuō)，之前條件是滿足的，但是現(xiàn)在已經(jīng)不滿足了，所以要重新檢驗(yàn)條件是否滿足。

實(shí)現(xiàn)代碼

我們優(yōu)化后的ResourcesRequester類的代碼如下所示。

public class ResourcesRequester{
    //存放申請(qǐng)資源的集合
    private List<Object> resources = new ArrayList<Object>();
    //一次申請(qǐng)所有的資源
    public synchronized void applyResources(Object source, Object target){
        while(resources.contains(source) || resources.contains(target)){
            try{
                wait();
            }catch(Exception e){
                e.printStackTrace();
            }
        }
        resources.add(source);
        resources.add(targer);
    }

    //釋放資源
    public synchronized void releaseResources(Object source, Object target){
        resources.remove(source);
        resources.remove(target);
        notifyAll();
    }
}

生成ResourcesRequester單例對(duì)象的Holder類ResourcesRequesterHolder的代碼如下所示。

public class ResourcesRequesterHolder{
    private ResourcesRequesterHolder(){}

    public static ResourcesRequester getInstance(){
        return Singleton.INSTANCE.getInstance();
    }
    private enum Singleton{
        INSTANCE;
        private ResourcesRequester singleton;
        Singleton(){
            singleton = new ResourcesRequester();
        }
        public ResourcesRequester getInstance(){
            return singleton;
        }
    }
}

執(zhí)行轉(zhuǎn)賬操作的類的代碼如下所示。

public class TansferAccount{
    //賬戶的余額
    private Integer balance;
    //ResourcesRequester類的單例對(duì)象
    private ResourcesRequester requester;

    public TansferAccount(Integer balance){
        this.balance = balance;
        this.requester = ResourcesRequesterHolder.getInstance();
    }
    //轉(zhuǎn)賬操作
    public void transfer(TansferAccount target, Integer transferMoney){
        //一次申請(qǐng)轉(zhuǎn)出賬戶和轉(zhuǎn)入賬戶，直到成功
        requester.applyResources(this, target))
        try{
            //對(duì)轉(zhuǎn)出賬戶加鎖
            synchronized(this){
                //對(duì)轉(zhuǎn)入賬戶加鎖
                synchronized(target){
                    if(this.balance >= transferMoney){
                        this.balance -= transferMoney;
                        target.balance += transferMoney;
                    }   
                }
            }
        }finally{
            //最后釋放賬戶資源
            requester.releaseResources(this, target);
        }
    }
}

可以看到，我們?cè)诔绦蛑型ㄖ幱诘却隣顟B(tài)的線程時(shí)，使用的是notifyAll()方法而不是notify()方法。那notify()方法和notifyAll()方法兩者有什么區(qū)別呢？

notify()方法和notifyAll()方法的區(qū)別

• notify()方法

隨機(jī)通知等待隊(duì)列中的一個(gè)線程。

• notifyAll()方法

通知等待隊(duì)列中的所有線程。

在實(shí)際工作過(guò)程中，如果沒(méi)有特殊的要求，盡量使用notifyAll()方法。因?yàn)槭褂胣otify()方法是有風(fēng)險(xiǎn)的，可能會(huì)導(dǎo)致某些線程永久不會(huì)被通知到！

寫在最后

最后，附上并發(fā)編程需要掌握的核心技能知識(shí)圖，祝大家在學(xué)習(xí)并發(fā)編程時(shí)，少走彎路。