如何提高 Java 中鎖的性能

兩個月前向plumbr公司引進線程死鎖的檢測之後，我們開始收到一些類似于這樣的詢問：“棒極了！現在我知道造成程式出現性能問題的原因了，但是接下來該怎麼做呢？”

我們努力為自己的産品所遇到的問題思考解決辦法，但在這篇文章中我将給大家分享幾種常用的技術，包括分離鎖、并行資料結構、保護資料而非代碼、縮小鎖的作用範圍，這幾種技術可以使我們不使用任何工具來檢測死鎖。

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

通常在多線程的代碼中遇到性能方面的問題時，一般都會抱怨是鎖的問題。畢竟鎖會降低程式的運作速度和其較低的擴充性是衆所周知的。是以，如果帶着這種“常識”開始優化代碼，其結果很有可能是在之後會出現讨人厭的并發問題。

是以，明白競争鎖和非競争鎖的不同是非常重要的。當一個線程試圖進入另一個線程正在執行的同步塊或方法時會觸發鎖競争。該線程會被強制進入等待狀态，直到第一個線程執行完同步塊并且已經釋放了螢幕。當同一時間隻有一個線程嘗試執行同步的代碼區域時，鎖會保持非競争的狀态。

事實上，在非競争的情況下和大多數的應用中，jvm已經對同步進行了優化。非競争鎖在執行過程中不會帶來任何額外的開銷。是以，你不應該因為性能問題抱怨鎖，應該抱怨的是鎖的競争。當有了這個認識之後，讓我們來看下能做些什麼，以降低競争的可能性或減少競争的持續時間。

保護資料而非代碼

解決線程安全問題的一個快速的方法就是對整個方法的可通路性加鎖。例如下面這個例子，試圖通過這種方法來建立一個線上撲克遊戲伺服器：

作者的意圖是好的——當一個新的玩家加入牌桌時，必須確定牌桌上的玩家個數不會超過牌桌可以容納的玩家總個數9。

但是這種解決辦法事實上無論何時都要對玩家進入牌桌進行控制——即使是在伺服器的通路量較小的時候也是這樣，那些等待鎖釋放的線程注定會頻繁的觸發系統的競争事件。包含對賬戶餘額和牌桌限制檢查的鎖定塊很可能大幅提高調用操作的開銷，而這無疑會增加競争的可能性和持續時間。

解決的第一步就是確定我們保護的是資料，而不是從方法聲明移到方法體中的那段同步聲明。對于上面那個簡單的例子來說，可能改變不大。但是我們要站在整個遊戲服務的接口之上來考慮，而不是單單的一個join()方法。

原本可能隻是一個小小的改變，影響的可是整個類的行為方式。玩家無論何時加入牌桌，先前的同步方法都會對整個gameserver執行個體加鎖，進而會與那些同時試圖離開牌桌的玩家産生競争。将鎖從方法聲明移到方法體中會延遲鎖的加載，進而降低了鎖競争的可能性。

縮小鎖的作用範圍

現在，當确信了需要保護的是資料而非程式後，我們應該確定我們隻在必要的地方加鎖——例如當上面的代碼被重構之後：

這樣那段包含對玩家賬号餘額檢測（可能引發io操作）的可能引起費時操作的代碼，被移到了鎖控制的範圍之外。注意，現在鎖僅僅被用來防止玩家人數超過桌子可容納的人數，對賬戶餘額的檢查不再是該保護措施的一部分了。

分離鎖

你可以從上面例子最後一行代碼清楚的看到：整個資料結構是由相同的鎖保護着。考慮到在這一種資料結構中可能會有數以千計的牌桌，而我們必須保護任何一張牌桌的人數不超過容量，在這樣的情況下仍然會有很高的風險出現競争事件。

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

在，我們隻對單一牌桌的可通路性進行同步而不是所有的牌桌，這樣就顯著降低了出現鎖競争的可能性。舉一個具體的例子，現在在我們的資料結構中有100個牌桌的執行個體，那麼現在發生競争的可能性就會比之前小100倍。

使用線程安全的資料結構

另一個可以改善的地方就是抛棄傳統的單線程資料結構，改用被明确設計為線程安全的資料結構。例如，當采用concurrenthashmap來儲存你的牌桌執行個體時，代碼可能像下面這樣：

在join()和leave()方法内部的同步塊仍然和先前的例子一樣，因為我們要保證單個牌桌資料的完整性。concurrenthashmap 在這點上并沒有任何幫助。但我們仍然會在increatetable()和destorytable()方法中使用concurrenthashmap建立和銷毀新的牌桌，所有這些操作對于concurrenthashmap來說是完全同步的，其允許我們以并行的方式添加或減少牌桌的數量。

其他一些建議和技巧

·        降低鎖的可見度。在上面的例子中，鎖被聲明為public（對外可見），這可能會使得一些别有用心的人通過在你精心設計的螢幕上加鎖來破壞你的工作。

·        通過檢視java.util.concurrent.locks 的api來看一下有沒有其它已經實作的鎖政策，使用其改進上面的解決方案。

·        使用原子操作。在上面正在使用的簡單遞增計數器實際上并不要求加鎖。上面的例子中更适合使用 atomicinteger代替integer作為計數器。

最後一點，無論你是否正在使用plumber的自動死鎖檢測解決方案，還是手動從線程轉儲獲得解決辦法的資訊，都希望這篇文章可以為你解決鎖競争的問題帶來幫助。