【高併發】高併發環境下詭異的加鎖問題（你加的鎖未必安全）

時間 2020-04-13

原文原文鏈接

聲明

特此聲明：文中有關支付寶帳戶的說明，只是用來舉例，實際支付寶帳戶要比文中描述的複雜的多。也與文中描述的徹底不一樣。java

前言

不少網友留言說：在編寫多線程併發程序時，我明明對共享資源加鎖了啊？爲何仍是出問題呢？問題到底出在哪裏呢？其實，我想說的是：你的加鎖姿式正確嗎？你真的會使用鎖嗎？錯誤的加鎖方式不但不能解決併發問題，並且還會帶來各類詭異的Bug問題，有時難以復現！編程

在上一篇《【高併發】如何使用互斥鎖解決多線程的原子性問題？此次終於明白了！》一文中，咱們知道在併發編程中，不能使用多把鎖保護同一個資源，由於這樣達不到線程互斥的效果，存在線程安全的問題。相反，卻可使用同一把鎖保護多個資源。那麼，如何使用同一把鎖保護多個資源呢？又如何判斷咱們對程序加的鎖究竟是不是安全的呢？咱們就一塊兒來深刻探討這些問題！安全

分析場景

咱們在分析多線程中如何使用同一把鎖保護多個資源時，能夠將其結合具體的業務場景來看，好比：須要保護的多個資源之間有沒有直接的業務關係。若是須要保護的資源之間沒有直接的業務關係，那麼如何對其加鎖；若是有直接的業務關係，那麼如何對其加鎖？接下來，咱們就順着這兩個方向進行深刻說明。微信

沒有直接業務關係的場景

例如，咱們的支付寶帳戶，有針對餘額的付款操做，也有針對帳戶密碼的修改操做。本質上，這兩種操做之間沒有直接的業務關係，此時，咱們能夠爲帳戶的餘額和帳戶密碼分配不一樣的鎖來解決併發問題。多線程

例如，在支付寶帳戶AlipayAccount類中，有兩個成員變量，分別是帳戶的餘額balance和帳戶的密碼password。付款操做的pay()方法和查看餘額操做的getBalance()方法會訪問帳戶中的成員變量balance，對此，咱們能夠建立一個balanceLock鎖對象來保護balance資源；另外，更改密碼操做的updatePassword()方法和查看密碼的getPassowrd()方法會訪問帳戶中的成員變量password，對此，咱們能夠建立一個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關鍵字。性能

可是，若是都使用同一個鎖對象的話，那麼，程序的性能就太差了。會致使沒有直接業務關係的各類操做都串行執行，這就違背了咱們併發編程的初衷。實際上，咱們使用兩個鎖對象分別保護balance資源和password資源，付款和修改帳戶密碼是能夠並行的。學習

存在直接業務關係的場景

例如，咱們使用支付寶進行轉帳操做。假設帳戶A給帳戶B轉帳100，A帳戶減小100元，B帳戶增長100元。兩個帳戶在業務中有直接的業務關係。例如，下面的TansferAccount類，有一個成員變量balance和一個轉帳的方法transfer()，代碼以下所示。this

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

在上面的代碼中，如何保證轉帳操做不會出現併發問題呢？不少時候咱們的第一反應就是給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臨界區中存在兩個不一樣的資源，分別是轉出帳戶的餘額this.balance和轉入帳戶的餘額target.balance，這裏只用到了一把鎖synchronized(this)。說到這裏，你們有沒有一種豁然開朗的感受。沒錯，問題就出如今synchronized(this)這把鎖上，這把鎖只能保護this.balance資源，而沒法保護target.balance資源。

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

從上圖咱們也能夠發現，this鎖對象只能保護this.balance資源，而不能保護target.balance資源。

接下來，咱們再看一個場景：假設存在A、B、C三個帳戶，餘額都是200，此時咱們使用兩個線程分別執行兩個轉帳操做：帳戶A給帳戶B轉帳100，帳戶B給帳戶C轉帳100。理論上，帳戶A的餘額爲100，帳戶B的餘額爲200，帳戶C的餘額爲300。

真的是這樣嗎？咱們假設線程A和線程B同時在兩個不一樣的CPU上執行，線程A執行帳戶A給帳戶B轉帳100的操做，線程B執行帳戶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的代碼根本沒法解決併發問題！

正確的加鎖

若是咱們但願對轉帳操做中涉及的多個資源加鎖，那咱們的鎖就必需要覆蓋全部須要保護的資源。

在前面的TansferAccount類中，this是對象級別的鎖，這就致使了線程A和線程B執行過程當中所獲取到的鎖是不一樣的，那麼如何讓兩個線程共享同一把鎖呢？！

其中，方案有不少，一種簡單的方式，就是在TansferAccount類的構造方法中傳入一個balanceLock鎖對象，之後在建立TansferAccount類對象的時候，每次傳入相同的balanceLock鎖對象，並在transfer方法中使用balanceLock鎖對象加鎖便可。這樣，全部建立的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;
            }   
        }
    }
}

那麼，問題又來了：這樣解決問題真的完美嗎？！

上述代碼雖然解決了轉帳操做的併發問題，可是它真的就完美了嗎？！仔細分析後，咱們發現，並非想象中的那麼完美。由於它要求建立TansferAccount對象的時候，必須傳入同一個balanceLock對象，若是傳入的不是同一個balanceLock對象，就不能保證併發帶來的線程安全問題了！在實際的項目中，建立TansferAccount對象的操做可能被分散在多個不一樣的項目工程中，這樣很難保證傳入的balanceLock對象是同一個對象。

因此，在建立TansferAccount對象時傳入同一個balanceLock鎖對象的方案，雖然可以解決轉帳的併發問題，可是卻沒法在實際項目中被有效的採用！

還有沒有其餘的方案呢？答案是有！別忘了JVM在加鎖類的時候，會爲類建立一個Class對象，而這個Class對象對於類的實例對象來講是共享的，也就是說，不管建立多少個類的實例對象，這個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;
            }   
        }
    }
}

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

這樣，不管建立多少個TansferAccount對象，都會共享同一把鎖，解決了轉帳的併發問題。