併發編程中,你加的鎖未必安全

語言: CN / TW / HK

摘要: 在編寫多線程併發程序時,我明明對共享資源加鎖了啊?為什麼還是出問題呢?問題到底出在哪裏呢?其實,我想説的是:你的加鎖姿勢正確嗎?

本文分享自華為雲社區《 【高併發】高併發環境下詭異的加鎖問題(你加的鎖未必安全) 》,作者:冰 河。

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

分析場景

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

沒有直接業務關係的場景

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

例如,在支付寶賬户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對象,都會共享同一把鎖,解決了轉賬的併發問題。

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