【高并發(fā)】高并發(fā)環(huán)境下詭異的加鎖問題(你加的鎖未必安全)
來自:冰河技術
聲明
特此聲明:文中有關支付寶賬戶的說明,只是用來舉例,實際支付寶賬戶要比文中描述的復雜的多。也與文中描述的完全不同。
前言
很多網友留言說:在編寫多線程并發(fā)程序時,我明明對共享資源加鎖了?。繛槭裁催€是出問題呢?問題到底出在哪里呢?其實,我想說的是:你的加鎖姿勢正確嗎?你真的會使用鎖嗎?錯誤的加鎖方式不但不能解決并發(fā)問題,而且還會帶來各種詭異的Bug問題,有時難以復現(xiàn)!
在之前的《【高并發(fā)】如何使用互斥鎖解決多線程的原子性問題?這次終于明白了!》一文中,我們知道在并發(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ā)編程時,少走彎路。
后記:
記?。?/span>你比別人強的地方,不是你做過多少年的CRUD工作,而是你比別人掌握了更多深入的技能。不要總停留在CRUD的表面工作,理解并掌握底層原理并熟悉源碼實現(xiàn),并形成自己的抽象思維能力,做到靈活運用,才是你突破瓶頸,脫穎而出的重要方向!
你在刷抖音,玩游戲的時候,別人都在這里學習,成長,提升,人與人最大的差距其實就是思維。你可能不信,優(yōu)秀的人,總是在一起。。
特別推薦一個分享架構+算法的優(yōu)質內容,還沒關注的小伙伴,可以長按關注一下:
長按訂閱更多精彩▼
如有收獲,點個在看,誠摯感謝
免責聲明:本文內容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!