閱讀目錄

一、儘量不要鎖住方法

二、縮小同步程式碼塊，只鎖資料

三、鎖中儘量不要再包含鎖

四、將鎖私有化，在內部管理鎖

五、進行適當的鎖分解

正文

併發環境下進行程式設計時，需要使用鎖機制來同步多執行緒間的操作，保證共享資源的互斥訪問。加鎖會帶來效能上的損壞，似乎是眾所周知的事情。然而，加鎖本身不會帶來多少的效能消耗，效能主要是線上程的獲取鎖的過程。

如果只有一個執行緒競爭鎖，此時並不存在多執行緒競爭的情況，那麼JVM會進行優化，那麼這時加鎖帶來的效能消耗基本可以忽略。因此，規範加鎖的操作，優化鎖的使用方法，避免不必要的執行緒競爭，不僅可以提高程式效能，也能避免不規範加鎖可能造成執行緒死鎖問題，提高程式健壯性。下面闡述幾種鎖優化的思路。

一、儘量不要鎖住方法

在普通成員函式上加鎖時，執行緒獲得的是該方法所在物件的物件鎖。此時整個物件都會被鎖住。這也意味著，如果這個物件提供的多個同步方法是針對不同業務的，那麼由於整個物件被鎖住，一個業務業務在處理時，其他不相關的業務執行緒也必須wait。下面的例子展示了這種情況：

LockMethod類包含兩個同步方法，分別在兩種業務處理中被呼叫：

 

BUSSA是執行緒類，用來處理A業務，呼叫的是LockMethod的busiA（）方法：

 

BUSSB是執行緒類，用來處理B業務，呼叫的是LockMethod的busiB（）方法：

 

TestLockMethod類，使用執行緒BUSSA與BUSSB進行業務處理：

 

執行程式，可以看到線上程bussa 執行的過程中，bussb是不能夠進入函式 busiB()的，因為此時lockMethod 的物件鎖被執行緒bussa獲取了。

二、縮小同步程式碼塊，只鎖資料

有時候為了程式設計方便，有些人會synchnoized很大的一塊程式碼，如果這個程式碼塊中的某些操作與共享資源並不相關，那麼應當把它們放到同步塊外部，避免長時間的持有鎖，造成其他執行緒一直處於等待狀態。尤其是一些迴圈操作、同步I/O操作。

不止是在程式碼的行數範圍上縮小同步塊，在執行邏輯上，也應該縮小同步塊，例如多加一些條件判斷，符合條件的再進行同步，而不是同步之後再進行條件判斷，儘量減少不必要的進入同步塊的邏輯。

三、鎖中儘量不要再包含鎖

這種情況經常發生，執行緒在得到了A鎖之後，在同步方法塊中呼叫了另外物件的同步方法，獲得了第二個鎖，這樣可能導致一個呼叫堆疊中有多把鎖的請求，多執行緒情況下可能會出現很複雜、難以分析的異常情況，導致死鎖的發生。下面的程式碼顯示了這種情況：

 

或是在同步塊中呼叫了同步方法：

 

解決的辦法是跳出來加鎖，不要包含加鎖：

 

四、將鎖私有化，在內部管理鎖

把鎖作為一個私有的物件，外部不能拿到這個物件，更安全一些。物件可能被其他執行緒直接進行加鎖操作，此時執行緒便持有了該物件的物件鎖，例如下面這種情況：

 

這種使用方式下，物件a的物件鎖被外部所持有，讓這把鎖在外部多個地方被使用是比較危險的，對程式碼的邏輯流程閱讀也造成困擾。一種更好的方式是在類的內部自己管理鎖，外部需要同步方案時，也是通過介面方式來提供同步操作：

五、進行適當的鎖分解

考慮下面這段程式：

 

在這個例子中，join方法只使用一個同步鎖，來獲取tables中的List物件，然後判斷玩家數量是不是小於9，如果是，就調增加一個玩家。當有成千上萬個List存在tables中時，對tables鎖的競爭將非常激烈。

在這裡，我們可以考慮進行鎖的分解：快速取出資料之後，對List物件進行加鎖，讓其他執行緒可快速競爭獲得tables物件鎖：

 

歡迎工作一到五年的Java工程師朋友們加入Java填坑之路：860113481

群內提供免費的Java架構學習資料（裡面有高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用”沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！