建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
作者個(gè)人研發(fā)的在高并發(fā)場(chǎng)景下，提供的簡(jiǎn)單、穩(wěn)定、可擴(kuò)展的延遲消息隊(duì)列框架，具有精準(zhǔn)的定時(shí)任務(wù)和延遲隊(duì)列處理功能。自開(kāi)源半年多以來(lái)，已成功為十幾家中小型企業(yè)提供了精準(zhǔn)定時(shí)調(diào)度方案，經(jīng)受住了生產(chǎn)環(huán)境的考驗(yàn)。為使更多童鞋受益，現(xiàn)給出開(kāi)源框架地址：https://github.com/sunshinelyz/mykit-delay。
聲明
特此聲明：文中有關(guān)支付寶賬戶(hù)的說(shuō)明，只是用來(lái)舉例，實(shí)際支付寶賬戶(hù)要比文中描述的復(fù)雜的多。也與文中描述的完全不同。
前言
很多網(wǎng)友留言說(shuō)：在編寫(xiě)多線(xiàn)程并發(fā)程序時(shí)，我明明對(duì)共享資源加鎖了啊?為什么還是出問(wèn)題呢?問(wèn)題到底出在哪里呢?其實(shí)，我想說(shuō)的是：你的加鎖姿勢(shì)正確嗎?你真的會(huì)使用鎖嗎?錯(cuò)誤的加鎖方式不但不能解決并發(fā)問(wèn)題，而且還會(huì)帶來(lái)各種詭異的Bug問(wèn)題，有時(shí)難以復(fù)現(xiàn)!
我們知道在并發(fā)編程中，不能使用多把鎖保護(hù)同一個(gè)資源，因?yàn)檫@樣達(dá)不到線(xiàn)程互斥的效果，存在線(xiàn)程安全的問(wèn)題。相反，卻可以使用同一把鎖保護(hù)多個(gè)資源。那么，如何使用同一把鎖保護(hù)多個(gè)資源呢?又如何判斷我們對(duì)程序加的鎖到底是不是安全的呢?我們就一起來(lái)深入探討這些問(wèn)題!
分析場(chǎng)景
我們?cè)诜治龆嗑€(xiàn)程中如何使用同一把鎖保護(hù)多個(gè)資源時(shí)，可以將其結(jié)合具體的業(yè)務(wù)場(chǎng)景來(lái)看，比如：需要保護(hù)的多個(gè)資源之間有沒(méi)有直接的業(yè)務(wù)關(guān)系。如果需要保護(hù)的資源之間沒(méi)有直接的業(yè)務(wù)關(guān)系，那么如何對(duì)其加鎖;如果有直接的業(yè)務(wù)關(guān)系，那么如何對(duì)其加鎖?接下來(lái)，我們就順著這兩個(gè)方向進(jìn)行深入說(shuō)明。
沒(méi)有直接業(yè)務(wù)關(guān)系的場(chǎng)景
例如，我們的支付寶賬戶(hù)，有針對(duì)余額的付款操作，也有針對(duì)賬戶(hù)密碼的修改操作。本質(zhì)上，這兩種操作之間沒(méi)有直接的業(yè)務(wù)關(guān)系，此時(shí)，我們可以為賬戶(hù)的余額和賬戶(hù)密碼分配不同的鎖來(lái)解決并發(fā)問(wèn)題。
例如，在支付寶賬戶(hù)AlipayAccount類(lèi)中，有兩個(gè)成員變量，分別是賬戶(hù)的余額balance和賬戶(hù)的密碼password。付款操作的pay()方法和查看余額操作的getBalance()方法會(huì)訪(fǎng)問(wèn)賬戶(hù)中的成員變量balance，對(duì)此，我們可以創(chuàng)建一個(gè)balanceLock鎖對(duì)象來(lái)保護(hù)balance資源;另外，更改密碼操作的updatePassword()方法和查看密碼的getPassowrd()方法會(huì)訪(fǎng)問(wèn)賬戶(hù)中的成員變量password，對(duì)此，我們可以創(chuàng)建一個(gè)passwordLock鎖對(duì)象來(lái)保護(hù)password資源。
具體的代碼如下所示。
- public class AlipayAccount{
- //保護(hù)balance資源的鎖對(duì)象
- private final Object balanceLock = new Object();
- //保護(hù)password資源的鎖對(duì)象
- private final Object passwordLock = new Object();
- //賬戶(hù)余額
- private Integer balance;
- //賬戶(hù)的密碼
- private String password;
- //支付方法
- public void pay(Integer money){
- synchronized(balanceLock){
- if(this.balance >= money){
- this.balance -= money;
- }
- }
- }
- //查看賬戶(hù)中的余額
- public Integer getBalance(){
- synchronized(balanceLock){
- return this.balance;
- }
- }
- //修改賬戶(hù)的密碼
- public void updatePassword(String password){
- synchronized(passwordLock){
- this.password = password;
- }
- }
- //查看賬戶(hù)的密碼
- public String getPassword(){
- synchronized(passwordLock){
- return this.password;
- }
- }
- }
這里，我們也可以使用一把互斥鎖來(lái)保護(hù)balance資源和password資源，例如都使用balanceLock鎖對(duì)象，也可以都使用passwordLock鎖對(duì)象，甚至也都可以使用this對(duì)象或者干脆每個(gè)方法前加一個(gè)synchronized關(guān)鍵字。
但是，如果都使用同一個(gè)鎖對(duì)象的話(huà)，那么，程序的性能就太差了。會(huì)導(dǎo)致沒(méi)有直接業(yè)務(wù)關(guān)系的各種操作都串行執(zhí)行，這就違背了我們并發(fā)編程的初衷。實(shí)際上，我們使用兩個(gè)鎖對(duì)象分別保護(hù)balance資源和password資源，付款和修改賬戶(hù)密碼是可以并行的。
存在直接業(yè)務(wù)關(guān)系的場(chǎng)景
例如，我們使用支付寶進(jìn)行轉(zhuǎn)賬操作。假設(shè)賬戶(hù)A給賬戶(hù)B轉(zhuǎn)賬100，A賬戶(hù)減少100元，B賬戶(hù)增加100元。兩個(gè)賬戶(hù)在業(yè)務(wù)中有直接的業(yè)務(wù)關(guān)系。例如，下面的TansferAccount類(lèi)，有一個(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ā)問(wèn)題呢?很多時(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)出賬戶(hù)的余額this.balance和轉(zhuǎn)入賬戶(hù)的余額target.balance，這里只用到了一把鎖synchronized(this)。說(shuō)到這里，大家有沒(méi)有一種豁然開(kāi)朗的感覺(jué)。沒(méi)錯(cuò)，問(wèn)題就出現(xiàn)在synchronized(this)這把鎖上，這把鎖只能保護(hù)this.balance資源，而無(wú)法保護(hù)target.balance資源。
我們可以使用下圖來(lái)表示這個(gè)邏輯。
從上圖我們也可以發(fā)現(xiàn)，this鎖對(duì)象只能保護(hù)this.balance資源，而不能保護(hù)target.balance資源。
接下來(lái)，我們?cè)倏匆粋€(gè)場(chǎng)景：假設(shè)存在A(yíng)、B、C三個(gè)賬戶(hù)，余額都是200，此時(shí)我們使用兩個(gè)線(xiàn)程分別執(zhí)行兩個(gè)轉(zhuǎn)賬操作：賬戶(hù)A給賬戶(hù)B轉(zhuǎn)賬100，賬戶(hù)B給賬戶(hù)C轉(zhuǎn)賬100。理論上，賬戶(hù)A的余額為100，賬戶(hù)B的余額為200，賬戶(hù)C的余額為300。
真的是這樣嗎?我們假設(shè)線(xiàn)程A和線(xiàn)程B同時(shí)在兩個(gè)不同的CPU上執(zhí)行，線(xiàn)程A執(zhí)行賬戶(hù)A給賬戶(hù)B轉(zhuǎn)賬100的操作，線(xiàn)程B執(zhí)行賬戶(hù)B給賬戶(hù)C轉(zhuǎn)賬100的操作。兩個(gè)線(xiàn)程之間是互斥的嗎?顯然不是，按照TansferAccount的代碼來(lái)看，線(xiàn)程A鎖定的是賬戶(hù)A的實(shí)例，線(xiàn)程B鎖定的是賬戶(hù)B的實(shí)例。所以，線(xiàn)程A和線(xiàn)程B能夠同時(shí)進(jìn)入transfer()方法。此時(shí)，線(xiàn)程A和線(xiàn)程B都能夠讀取到賬戶(hù)B的余額為200。兩個(gè)線(xiàn)程都完成轉(zhuǎn)賬操作后，B的賬戶(hù)余額可能為300，也可能為100，但是不可能為200。
這是為什么呢?線(xiàn)程A和線(xiàn)程B同時(shí)讀取到賬戶(hù)B的余額為200，如果線(xiàn)程A的轉(zhuǎn)賬操作晚于線(xiàn)程B的轉(zhuǎn)賬操作對(duì)balance的寫(xiě)入，則賬戶(hù)B的余額為300;如果線(xiàn)程A的轉(zhuǎn)賬操作早于線(xiàn)程B的轉(zhuǎn)賬操作對(duì)balance的寫(xiě)入，則賬戶(hù)B的余額為100。無(wú)論如何賬戶(hù)B的余額都不會(huì)是200。
綜上所示，TansferAccount的代碼根本無(wú)法解決并發(fā)問(wèn)題!
正確的加鎖
如果我們希望對(duì)轉(zhuǎn)賬操作中涉及的多個(gè)資源加鎖，那我們的鎖就必須要覆蓋所有需要保護(hù)的資源。
在前面的TansferAccount類(lèi)中，this是對(duì)象級(jí)別的鎖，這就導(dǎo)致了線(xiàn)程A和線(xiàn)程B執(zhí)行過(guò)程中所獲取到的鎖是不同的，那么如何讓兩個(gè)線(xiàn)程共享同一把鎖呢?!
其中，方案有很多，一種簡(jiǎn)單的方式，就是在TansferAccount類(lèi)的構(gòu)造方法中傳入一個(gè)balanceLock鎖對(duì)象，以后在創(chuàng)建TansferAccount類(lèi)對(duì)象的時(shí)候，每次傳入相同的balanceLock鎖對(duì)象，并在transfer方法中使用balanceLock鎖對(duì)象加鎖即可。這樣，所有創(chuàng)建的TansferAccount類(lèi)對(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;
- }
- }
- }
- }
那么，問(wèn)題又來(lái)了：這樣解決問(wèn)題真的完美嗎?!
上述代碼雖然解決了轉(zhuǎn)賬操作的并發(fā)問(wèn)題，但是它真的就完美了嗎?!仔細(xì)分析后，我們發(fā)現(xiàn)，并不是想象中的那么完美。因?yàn)樗髣?chuàng)建TansferAccount對(duì)象的時(shí)候，必須傳入同一個(gè)balanceLock對(duì)象，如果傳入的不是同一個(gè)balanceLock對(duì)象，就不能保證并發(fā)帶來(lái)的線(xiàn)程安全問(wèn)題了!在實(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ā)問(wèn)題，但是卻無(wú)法在實(shí)際項(xiàng)目中被有效的采用!
還有沒(méi)有其他的方案呢?答案是有!別忘了JVM在加鎖類(lèi)的時(shí)候，會(huì)為類(lèi)創(chuàng)建一個(gè)Class對(duì)象，而這個(gè)Class對(duì)象對(duì)于類(lèi)的實(shí)例對(duì)象來(lái)說(shuō)是共享的，也就是說(shuō)，無(wú)論創(chuàng)建多少個(gè)類(lèi)的實(shí)例對(duì)象，這個(gè)Class對(duì)象都是同一個(gè)，這是由JVM來(lái)保證的。
說(shuō)到這里，我們就能夠想到使用如下方式對(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è)邏輯。
這樣，無(wú)論創(chuàng)建多少個(gè)TansferAccount對(duì)象，都會(huì)共享同一把鎖，解決了轉(zhuǎn)賬的并發(fā)問(wèn)題。
寫(xiě)在最后
如果覺(jué)得文章對(duì)你有點(diǎn)幫助，請(qǐng)微信搜索并關(guān)注「 冰河技術(shù) 」微信公眾號(hào)，跟冰河學(xué)習(xí)高并發(fā)編程技術(shù)。
最后，附上并發(fā)編程需要掌握的核心技能知識(shí)圖，祝大家在學(xué)習(xí)并發(fā)編程時(shí)，少走彎路。
后記
記?。耗惚葎e人強(qiáng)的地方，不是你做過(guò)多少年的CRUD工作，而是你比別人掌握了更多深入的技能。不要總停留在CRUD的表面工作，理解并掌握底層原理并熟悉源碼實(shí)現(xiàn)，并形成自己的抽象思維能力，做到靈活運(yùn)用，才是你突破瓶頸，脫穎而出的重要方向!
你在刷抖音，玩游戲的時(shí)候，別人都在這里學(xué)習(xí)，成長(zhǎng)，提升，人與人最大的差距其實(shí)就是思維。你可能不信，優(yōu)秀的人，總是在一起。
本文轉(zhuǎn)載自微信公眾號(hào)「冰河技術(shù)」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系冰河技術(shù)公眾號(hào)。
本文標(biāo)題：高并發(fā)環(huán)境下詭異的加鎖問(wèn)題（你加的鎖未必安全）
文章路徑：http://www.5511xx.com/article/dpcgpeg.html
