併發程式設計中，你加的鎖未必安全

華為雲開發者社群發表於2021-11-29
程式設計
摘要：在編寫多執行緒併發程式時，我明明對共享資源加鎖了啊？為什麼還是出問題呢？問題到底出在哪裡呢？其實，我想說的是：你的加鎖姿勢正確嗎？

本文分享自華為雲社群《【高併發】高併發環境下詭異的加鎖問題（你加的鎖未必安全）》，作者：冰 河。

我們知道在併發程式設計中，不能使用多把鎖保護同一個資源，因為這樣達不到執行緒互斥的效果，存線上程安全的問題。相反，卻可以使用同一把鎖保護多個資源。那麼，如何使用同一把鎖保護多個資源呢？又如何判斷我們對程式加的鎖到底是不是安全的呢？我們就一起來深入探討這些問題！

分析場景

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

沒有直接業務關係的場景

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

例如，在支付寶賬戶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()，程式碼如下所示。

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物件，都會共享同一把鎖，解決了轉賬的併發問題。

 

點選關注，第一時間瞭解華為雲新鮮技術~

相關文章