作者個人研發(fā)的在高并發(fā)場景下，提供的簡單、穩(wěn)定、可擴展的延遲消息隊列框架，具有精準的定時任務和延遲隊列處理功能。自開源半年多以來，已成功為十幾家中小型企業(yè)提供了精準定時調度方案，經受住了生產環(huán)境的考驗。為使更多童鞋受益，現(xiàn)給出開源框架地址：https://github.com/sunshinelyz/mykit-delay。

[[322243]]

聲明

特此聲明：文中有關支付寶賬戶的說明，只是用來舉例，實際支付寶賬戶要比文中描述的復雜的多。也與文中描述的完全不同。

前言

很多網友留言說：在編寫多線程并發(fā)程序時，我明明對共享資源加鎖了啊?為什么還是出問題呢?問題到底出在哪里呢?其實，我想說的是：你的加鎖姿勢正確嗎?你真的會使用鎖嗎?錯誤的加鎖方式不但不能解決并發(fā)問題，而且還會帶來各種詭異的Bug問題，有時難以復現(xiàn)!

我們知道在并發(fā)編程中，不能使用多把鎖保護同一個資源，因為這樣達不到線程互斥的效果，存在線程安全的問題。相反，卻可以使用同一把鎖保護多個資源。那么，如何使用同一把鎖保護多個資源呢?又如何判斷我們對程序加的鎖到底是不是安全的呢?我們就一起來深入探討這些問題!

分析場景

我們在分析多線程中如何使用同一把鎖保護多個資源時，可以將其結合具體的業(yè)務場景來看，比如：需要保護的多個資源之間有沒有直接的業(yè)務關系。如果需要保護的資源之間沒有直接的業(yè)務關系，那么如何對其加鎖;如果有直接的業(yè)務關系，那么如何對其加鎖?接下來，我們就順著這兩個方向進行深入說明。

沒有直接業(yè)務關系的場景

例如，我們的支付寶賬戶，有針對余額的付款操作，也有針對賬戶密碼的修改操作。本質上，這兩種操作之間沒有直接的業(yè)務關系，此時，我們可以為賬戶的余額和賬戶密碼分配不同的鎖來解決并發(fā)問題。

例如，在支付寶賬戶AlipayAccount類中，有兩個成員變量，分別是賬戶的余額balance和賬戶的密碼password。付款操作的pay()方法和查看余額操作的getBalance()方法會訪問賬戶中的成員變量balance，對此，我們可以創(chuàng)建一個balanceLock鎖對象來保護balance資源;另外，更改密碼操作的updatePassword()方法和查看密碼的getPassowrd()方法會訪問賬戶中的成員變量password，對此，我們可以創(chuàng)建一個passwordLock鎖對象來保護password資源。

具體的代碼如下所示。

public class AlipayAccount{ 
    //保護balance資源的鎖對象 
    private final Object balanceLock = new Object(); 
    //保護password資源的鎖對象 
    private final Object passwordLock = new Object(); 
    //賬戶余額 
    private Integer balance; 
    //賬戶的密碼 
    private String password; 
 
    //支付方法 
    public void pay(Integer money){ 
        synchronized(balanceLock){ 
            if(this.balance >= money){ 
                this.balance -= money; 
            } 
        } 
    } 
    //查看賬戶中的余額 
    public Integer getBalance(){ 
        synchronized(balanceLock){ 
            return this.balance; 
        } 
    } 
 
    //修改賬戶的密碼 
    public void updatePassword(String password){ 
        synchronized(passwordLock){ 
            this.password = password; 
        } 
    } 
 
    //查看賬戶的密碼 
    public String getPassword(){ 
        synchronized(passwordLock){ 
            return this.password; 
        } 
    } 
} 

這里，我們也可以使用一把互斥鎖來保護balance資源和password資源，例如都使用balanceLock鎖對象，也可以都使用passwordLock鎖對象，甚至也都可以使用this對象或者干脆每個方法前加一個synchronized關鍵字。

但是，如果都使用同一個鎖對象的話，那么，程序的性能就太差了。會導致沒有直接業(yè)務關系的各種操作都串行執(zhí)行，這就違背了我們并發(fā)編程的初衷。實際上，我們使用兩個鎖對象分別保護balance資源和password資源，付款和修改賬戶密碼是可以并行的。

存在直接業(yè)務關系的場景

例如，我們使用支付寶進行轉賬操作。假設賬戶A給賬戶B轉賬100，A賬戶減少100元，B賬戶增加100元。兩個賬戶在業(yè)務中有直接的業(yè)務關系。例如，下面的TansferAccount類，有一個成員變量balance和一個轉賬的方法transfer()，代碼如下所示。

public class TansferAccount{ 
    private Integer balance; 
    public void transfer(TansferAccount target, Integer transferMoney){ 
        if(this.balance >= transferMoney){ 
            this.balance -= transferMoney; 
            target.balance += transferMoney; 
        } 
    } 
} 

在上面的代碼中，如何保證轉賬操作不會出現(xiàn)并發(fā)問題呢?很多時候我們的第一反應就是給transfer()方法加鎖，如下代碼所示。

public class TansferAccount{ 
    private Integer balance; 
    public synchronized void transfer(TansferAccount target, Integer transferMoney){ 
        if(this.balance >= transferMoney){ 
            this.balance -= transferMoney; 
            target.balance += transferMoney; 
        } 
    } 
} 

我們仔細分析下，上面的代碼真的是安全的嗎?!其實，在這段代碼中，synchronized臨界區(qū)中存在兩個不同的資源，分別是轉出賬戶的余額this.balance和轉入賬戶的余額target.balance，這里只用到了一把鎖synchronized(this)。說到這里，大家有沒有一種豁然開朗的感覺。沒錯，問題就出現(xiàn)在synchronized(this)這把鎖上，這把鎖只能保護this.balance資源，而無法保護target.balance資源。

我們可以使用下圖來表示這個邏輯。

從上圖我們也可以發(fā)現(xiàn)，this鎖對象只能保護this.balance資源，而不能保護target.balance資源。

接下來，我們再看一個場景：假設存在A、B、C三個賬戶，余額都是200，此時我們使用兩個線程分別執(zhí)行兩個轉賬操作：賬戶A給賬戶B轉賬100，賬戶B給賬戶C轉賬100。理論上，賬戶A的余額為100，賬戶B的余額為200，賬戶C的余額為300。

真的是這樣嗎?我們假設線程A和線程B同時在兩個不同的CPU上執(zhí)行，線程A執(zhí)行賬戶A給賬戶B轉賬100的操作，線程B執(zhí)行賬戶B給賬戶C轉賬100的操作。兩個線程之間是互斥的嗎?顯然不是，按照TansferAccount的代碼來看，線程A鎖定的是賬戶A的實例，線程B鎖定的是賬戶B的實例。所以，線程A和線程B能夠同時進入transfer()方法。此時，線程A和線程B都能夠讀取到賬戶B的余額為200。兩個線程都完成轉賬操作后，B的賬戶余額可能為300，也可能為100，但是不可能為200。

這是為什么呢?線程A和線程B同時讀取到賬戶B的余額為200，如果線程A的轉賬操作晚于線程B的轉賬操作對balance的寫入，則賬戶B的余額為300;如果線程A的轉賬操作早于線程B的轉賬操作對balance的寫入，則賬戶B的余額為100。無論如何賬戶B的余額都不會是200。

綜上所示，TansferAccount的代碼根本無法解決并發(fā)問題!

正確的加鎖

如果我們希望對轉賬操作中涉及的多個資源加鎖，那我們的鎖就必須要覆蓋所有需要保護的資源。

在前面的TansferAccount類中，this是對象級別的鎖，這就導致了線程A和線程B執(zhí)行過程中所獲取到的鎖是不同的，那么如何讓兩個線程共享同一把鎖呢?!

其中，方案有很多，一種簡單的方式，就是在TansferAccount類的構造方法中傳入一個balanceLock鎖對象，以后在創(chuàng)建TansferAccount類對象的時候，每次傳入相同的balanceLock鎖對象，并在transfer方法中使用balanceLock鎖對象加鎖即可。這樣，所有創(chuàng)建的TansferAccount類對象就會共享balanceLock鎖。代碼如下所示。

public class TansferAccount{ 
    private Integer balance; 
    private Object balanceLock; 
    private TansferAccount(){} 
    public TansferAccount(Object balanceLock){ 
        this.balanceLock = balanceLock; 
    } 
    public void transfer(TansferAccount target, Integer transferMoney){ 
        synchronized(this.balanceLock){ 
             if(this.balance >= transferMoney){ 
                this.balance -= transferMoney; 
                target.balance += transferMoney; 
            }    
        } 
    } 
} 

那么，問題又來了：這樣解決問題真的完美嗎?!

上述代碼雖然解決了轉賬操作的并發(fā)問題，但是它真的就完美了嗎?!仔細分析后，我們發(fā)現(xiàn)，并不是想象中的那么完美。因為它要求創(chuàng)建TansferAccount對象的時候，必須傳入同一個balanceLock對象，如果傳入的不是同一個balanceLock對象，就不能保證并發(fā)帶來的線程安全問題了!在實際的項目中，創(chuàng)建TansferAccount對象的操作可能被分散在多個不同的項目工程中，這樣很難保證傳入的balanceLock對象是同一個對象。

所以，在創(chuàng)建TansferAccount對象時傳入同一個balanceLock鎖對象的方案，雖然能夠解決轉賬的并發(fā)問題，但是卻無法在實際項目中被有效的采用!

還有沒有其他的方案呢?答案是有!別忘了JVM在加鎖類的時候，會為類創(chuàng)建一個Class對象，而這個Class對象對于類的實例對象來說是共享的，也就是說，無論創(chuàng)建多少個類的實例對象，這個Class對象都是同一個，這是由JVM來保證的。

說到這里，我們就能夠想到使用如下方式對轉賬操作加鎖。

public class TansferAccount{ 
    private Integer balance; 
    public void transfer(TansferAccount target, Integer transferMoney){ 
        synchronized(TansferAccount.class){ 
            if(this.balance >= transferMoney){ 
                this.balance -= transferMoney; 
                target.balance += transferMoney; 
            }    
        } 
    } 
} 

我們可以使用下圖表示這個邏輯。

這樣，無論創(chuàng)建多少個TansferAccount對象，都會共享同一把鎖，解決了轉賬的并發(fā)問題。

寫在最后

如果覺得文章對你有點幫助，請微信搜索并關注「 冰河技術 」微信公眾號，跟冰河學習高并發(fā)編程技術。

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

后記

記住：你比別人強的地方，不是你做過多少年的CRUD工作，而是你比別人掌握了更多深入的技能。不要總停留在CRUD的表面工作，理解并掌握底層原理并熟悉源碼實現(xiàn)，并形成自己的抽象思維能力，做到靈活運用，才是你突破瓶頸，脫穎而出的重要方向!

你在刷抖音，玩游戲的時候，別人都在這里學習，成長，提升，人與人最大的差距其實就是思維。你可能不信，優(yōu)秀的人，總是在一起。。

本文轉載自微信公眾號「冰河技術」，可以通過以下二維碼關注。轉載本文請聯(lián)系冰河技術公眾號。