摘要：我們知道在并發(fā)編程中，不能使用多把鎖保護(hù)同一個(gè)資源，因?yàn)檫@樣達(dá)不到線程互斥的效果，存在線程安全的問題。兩個(gè)線程都完成轉(zhuǎn)賬操作后，的賬戶余額可能為，也可能為，但是不可能為。

摘要：在編寫多線程并發(fā)程序時(shí)，我明明對(duì)共享資源加鎖了?。繛槭裁催€是出問題呢？問題到底出在哪里呢？其實(shí)，我想說的是：你的加鎖姿勢(shì)正確嗎？

本文分享自華為云社區(qū)《【高并發(fā)】高并發(fā)環(huán)境下詭異的加鎖問題（你加的鎖未必安全）》，作者：冰 河。

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

分析場(chǎng)景

我們?cè)诜治龆嗑€程中如何使用同一把鎖保護(hù)多個(gè)資源時(shí)，可以將其結(jié)合具體的業(yè)務(wù)場(chǎng)景來看，比如：需要保護(hù)的多個(gè)資源之間有沒有直接的業(yè)務(wù)關(guān)系。如果需要保護(hù)的資源之間沒有直接的業(yè)務(wù)關(guān)系，那么如何對(duì)其加鎖；如果有直接的業(yè)務(wù)關(guān)系，那么如何對(duì)其加鎖？接下來，我們就順著這兩個(gè)方向進(jìn)行深入說明。

沒有直接業(yè)務(wù)關(guān)系的場(chǎng)景

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

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

具體的代碼如下所示。

public class AlipayAccount{    //保護(hù)balance資源的鎖對(duì)象    private final Object balanceLock = new Object();    //保護(hù)password資源的鎖對(duì)象    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;        }    }}

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

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

存在直接業(yè)務(wù)關(guān)系的場(chǎng)景

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

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

在上面的代碼中，如何保證轉(zhuǎn)賬操作不會(huì)出現(xiàn)并發(fā)問題呢？很多時(shí)候我們的第一反應(yīng)就是給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;        }    }}

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

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

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

接下來，我們?cè)倏匆粋€(gè)場(chǎng)景：假設(shè)存在A、B、C三個(gè)賬戶，余額都是200，此時(shí)我們使用兩個(gè)線程分別執(zhí)行兩個(gè)轉(zhuǎn)賬操作：賬戶A給賬戶B轉(zhuǎn)賬100，賬戶B給賬戶C轉(zhuǎn)賬100。理論上，賬戶A的余額為100，賬戶B的余額為200，賬戶C的余額為300。

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

這是為什么呢？線程A和線程B同時(shí)讀取到賬戶B的余額為200，如果線程A的轉(zhuǎn)賬操作晚于線程B的轉(zhuǎn)賬操作對(duì)balance的寫入，則賬戶B的余額為300；如果線程A的轉(zhuǎn)賬操作早于線程B的轉(zhuǎn)賬操作對(duì)balance的寫入，則賬戶B的余額為100。無論如何賬戶B的余額都不會(huì)是200。

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

正確的加鎖

如果我們希望對(duì)轉(zhuǎn)賬操作中涉及的多個(gè)資源加鎖，那我們的鎖就必須要覆蓋所有需要保護(hù)的資源。

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

其中，方案有很多，一種簡(jiǎn)單的方式，就是在TansferAccount類的構(gòu)造方法中傳入一個(gè)balanceLock鎖對(duì)象，以后在創(chuàng)建TansferAccount類對(duì)象的時(shí)候，每次傳入相同的balanceLock鎖對(duì)象，并在transfer方法中使用balanceLock鎖對(duì)象加鎖即可。這樣，所有創(chuàng)建的TansferAccount類對(duì)象就會(huì)共享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;            }           }    }}

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

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

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

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

說到這里，我們就能夠想到使用如下方式對(duì)轉(zhuǎn)賬操作加鎖。

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;            }           }    }}

我們可以使用下圖表示這個(gè)邏輯。

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

?

點(diǎn)擊關(guān)注，第一時(shí)間了解華為云新鮮技術(shù)~