兩個(gè)月前向Plumbr公司引進(jìn)線程死鎖的檢測之后，我們開始收到一些類似于這樣的詢問：“棒極了！現(xiàn)在我知道造成程序出現(xiàn)性能問題的原因了，但是接下來該怎么做呢？”

　　我們努力為自己的產(chǎn)品所遇到的問題思考解決辦法，但在這篇文章中我將給大家分享幾種常用的技術(shù)，包括分離鎖、并行數(shù)據(jù)結(jié)構(gòu)、保護(hù)數(shù)據(jù)而非代碼、縮小鎖的作用范圍，這幾種技術(shù)可以使我們不使用任何工具來檢測死鎖。

　　鎖不是問題的根源，鎖之間的競爭才是

　　通常在多線程的代碼中遇到性能方面的問題時(shí)，一般都會抱怨是鎖的問題。畢竟鎖會降低程序的運(yùn)行速度和其較低的擴(kuò)展性是眾所周知的。因此，如果帶著這種“常識”開始優(yōu)化代碼，其結(jié)果很有可能是在之后會出現(xiàn)討人厭的并發(fā)問題。

　　因此，明白競爭鎖和非競爭鎖的不同是非常重要的。當(dāng)一個(gè)線程試圖進(jìn)入 另一個(gè)線程正在執(zhí)行的同步塊或方法時(shí)會觸發(fā)鎖競爭。該線程會被強(qiáng)制進(jìn)入等待狀態(tài)，直到第一個(gè)線程執(zhí)行完同步塊并且已經(jīng)釋放了監(jiān)視器。當(dāng)同一時(shí)間只有一個(gè)線 程嘗試執(zhí)行同步的代碼區(qū)域時(shí)，鎖會保持非競爭的狀態(tài)。

　　事實(shí)上，在非競爭的情況下和大多數(shù)的應(yīng)用中，JVM已經(jīng)對同步進(jìn)行了優(yōu)化。非競爭鎖在執(zhí)行過程中不會帶來任何額外的開銷。因此，你不應(yīng)該因?yàn)樾阅軉栴}抱怨鎖，應(yīng)該抱怨的是鎖的競爭。當(dāng)有了這個(gè)認(rèn)識之后，讓我們來看下能做些什么，以降低競爭的可能性或減少競爭的持續(xù)時(shí)間。

　　保護(hù)數(shù)據(jù)而非代碼

　　解決線程安全問題的一個(gè)快速的方法就是對整個(gè)方法的可訪問性加鎖。例如下面這個(gè)例子，試圖通過這種方法來建立一個(gè)在線撲克游戲服務(wù)器：

　　class GameServer { publicMap《《String， List《Player》》 tables = newHashMap《String， List《Player》》（）; publicsynchronizedvoidjoin（Player player， Table table） {if（player.getAccountBalance（） 》 table.getLimit（）） { List《Player》 tablePlayers = tables.get（table.getId（））; if（tablePlayers.size（） 《 9） { tablePlayers.add（player）; } } }publicsynchronizedvoidleave（Player player， Table table） { /*body skipped for brevity*/}publicsynchronizedvoidcreateTable（） { /*body skipped for brevity*/}publicsynchronizedvoiddestroyTable（Table table） { /*body skipped for brevity*/} }

　　作者的意圖是好的——當(dāng)一個(gè)新的玩家加入牌桌 時(shí)，必須確保牌桌上的玩家個(gè)數(shù)不會超過牌桌可以容納的玩家總個(gè)數(shù)9。

　　但是這種解決辦法事實(shí)上無論何時(shí)都要對玩家進(jìn)入牌桌進(jìn)行控制——即使是在服務(wù)器的訪問量較小的時(shí)候也是這樣，那些等 待鎖釋放的線程注定會頻繁的觸發(fā)系統(tǒng)的競爭事件。包含對賬戶余額和牌桌限制檢查的鎖定塊很可能大幅提高調(diào)用操作的開銷，而這無疑會增加競爭的可能性和持續(xù) 時(shí)間。

　　解決的第一步就是確保我們保護(hù)的是數(shù)據(jù)，而不是從方法聲明移到方法體中的那段同步聲明。對于上面那個(gè)簡單的例子來說，可能改變不大。但是我們要站在整個(gè)游戲服務(wù)的接口之上來考慮，而不是單單的一個(gè)join（）方法。

　　class GameServer { publicMap《String， List《Player》》 tables = newHashMap《String， List《Player》》（）; publicvoidjoin（Player player， Table table） { synchronized （tables） {if（player.getAccountBalance（） 》 table.getLimit（）） { List《Player》 tablePlayers = tables.get（table.getId（））; if（tablePlayers.size（） 《 9） { tablePlayers.add（player）; } } } }publicvoidleave（Player player， Table table） { /* body skipped for brevity */}publicvoidcreateTable（） { /* body skipped for brevity */} publicvoiddestroyTable（Table table） { /* body skipped for brevity */} }

　　原本可能只是一個(gè)小小的改變，影響的可是整個(gè)類的行為方式。玩家無論何時(shí)加入牌桌，先前的同步方法都會對整個(gè)GameServer實(shí)例加鎖，進(jìn)而會與那些同時(shí)試圖離開牌桌的玩家產(chǎn)生競爭。將鎖從方法聲明移到方法體中會延遲鎖的加載，進(jìn)而降低了鎖競爭的可能性。

　　縮小鎖的作用范圍

　　現(xiàn)在，當(dāng)確信了需要保護(hù)的是數(shù)據(jù)而非程序后，我們應(yīng)該確保我們只在必要的地方加鎖——例如當(dāng)上面的代碼被重構(gòu)之后：

　　/** * Java學(xué)習(xí)交流QQ群：589809992 我們一起學(xué)Java！ */publicclassGameServer{publicMap《String， List《Player》》 tables = newHashMap《String， List《Player》》（）; publicvoidjoin（Player player， Table table） { if（player.getAccountBalance（） 》 table.getLimit（）） { synchronized（tables） { List《Player》 tablePlayers = tables.get（table.getId（））; if（tablePlayers.size（） 《 9） { tablePlayers.add（player）; } } } } //other methods skipped for brevity}

　　這樣那段包含對玩家賬號余額檢測（可能引發(fā)IO操作）的可能引起費(fèi)時(shí)操作的代碼，被移到了鎖控制的范圍之外。注意，現(xiàn)在鎖僅僅被用來防止玩家人數(shù)超過桌子可容納的人數(shù)，對賬戶余額的檢查不再是該保護(hù)措施的一部分了。

　　分離鎖

　　你可以從上面例子最后一行代碼清楚的看到：整個(gè)數(shù)據(jù)結(jié)構(gòu)是由相同的鎖保護(hù)著?？紤]到在這一種數(shù)據(jù)結(jié)構(gòu)中可能會有數(shù)以千計(jì)的牌桌，而我們必須保護(hù)任何一張牌桌的人數(shù)不超過容量，在這樣的情況下仍然會有很高的風(fēng)險(xiǎn)出現(xiàn)競爭事件。

　　關(guān)于這個(gè)有一個(gè)簡單的辦法，就是對每一張牌桌引入分離鎖，如下面這個(gè)例子所示：

　　/** * Java學(xué)習(xí)交流QQ群：589809992 我們一起學(xué)Java！ */publicclassGameServer{publicMap《String， List《Player》》 tables = newHashMap《String， List《Player》》（）; publicvoidjoin（Player player， Table table） { if（player.getAccountBalance（） 》 table.getLimit（）） { List《Player》 tablePlayers = tables.get（table.getId（））;synchronized（tablePlayers） { if（tablePlayers.size（） 《 9） { tablePlayers.add（player）; } } } }//other methods skipped for brevity}

　　現(xiàn)在，我們只對單一牌桌的可訪問性進(jìn)行同步而不是所有的牌桌，這樣就顯著降低了出現(xiàn)鎖競爭的可能性。舉一個(gè)具體的例子，現(xiàn)在在我們的數(shù)據(jù)結(jié)構(gòu)中有100個(gè)牌桌的實(shí)例，那么現(xiàn)在發(fā)生競爭的可能性就會比之前小100倍。

　　使用線程安全的數(shù)據(jù)結(jié)構(gòu)

　　另一個(gè)可以改善的地方就是拋棄傳統(tǒng)的單線程數(shù)據(jù)結(jié)構(gòu)，改用被明確設(shè)計(jì)為線程安全的數(shù)據(jù)結(jié)構(gòu)。例如，當(dāng)采用ConcurrentHashMap來儲存你的牌桌實(shí)例時(shí)，代碼可能像下面這樣：

　　publicclassGameServer{publicMap《String， List《Player》》 tables =newConcurrentHashMap《String， List《Player》》（）; publicsynchronizedvoidjoin（Player player， Table table） { /*Method body skipped for brevity*/}publicsynchronizedvoidleave（Player player， Table table） { /*Method body skipped for brevity*/} publicsynchronizedvoidcreateTable（） { Table table = newTable（）; tables.put（table.getId（）， table）; } publicsynchronizedvoiddestroyTable（Table table） { tables.remove（table.getId（））; } }

　　在join（）和leave（）方法內(nèi)部的同步塊仍然和先前的例子一樣，因?yàn)槲覀円ＷC單個(gè)牌桌數(shù)據(jù)的完整性。ConcurrentHashMap 在這點(diǎn)上并沒有任何幫助。但我們?nèi)匀粫趇ncreateTable（）和destoryTable（）方法中使用ConcurrentHashMap創(chuàng)建和銷毀新的牌桌，所有這些操作對于ConcurrentHashMap來說是完全同步的，其允許我們以并行的方式添加或減少牌桌的數(shù)量。

　　其他一些建議和技巧

　　降低鎖的可見度。在上面的例子中，鎖被聲明為public（對外可見），這可能會使得一些別有用心的人通過在你精心設(shè)計(jì)的監(jiān)視器上加鎖來破壞你的工作。

　　通過查看java.util.concurrent.locks 的API來看一下 有沒有其它已經(jīng)實(shí)現(xiàn)的鎖策略，使用其改進(jìn)上面的解決方案。

　　使用原子操作。在上面正在使用的簡單遞增計(jì)數(shù)器實(shí)際上并不要求加鎖。上面的例子中更適合使用 AtomicInteger代替Integer作為計(jì)數(shù)器。

　　最后一點(diǎn)，無論你是否正在使用Plumber的自動死鎖檢測解決方案，還是手動從線程轉(zhuǎn)儲獲得解決辦法的信息，都希望這篇文章可以為你解決鎖競爭的問題帶來幫助。

相關(guān)電子資料下載

• 一文詳解ZGC關(guān)鍵技術(shù) 26
• SpringBoot物理線程、虛擬線程、Webflux性能比較 37
• Rust語言為什么這么卷？ 21
• 什么是分布式鎖 Redis的五種分布式鎖方案 32
• Guava中這些Map的操作，讓我的代碼量減少了50% 70
• java實(shí)現(xiàn)定時(shí)器的四種方式 83
• 基于OkHttp 3.10.0的源碼案例解析 26
• 如何用Rust通過JNI和Java進(jìn)行交互 120
• JVM指針壓縮的工作原理 66
• 什么是SQL注入？Java項(xiàng)目防止SQL注入方式 37