閱讀目錄
一、盡量不要鎖住方法
二、縮小同步代碼塊，隻鎖資料
三、鎖中盡量不要再包含鎖
四、将鎖私有化，在内部管理鎖
五、進行适當的鎖分解
正文
并發環境下進行程式設計時，需要使用鎖機制來同步多線程間的操作，保證共享資源的互斥通路。加鎖會帶來性能上的損壞，似乎是衆所周知的事情。然而，加鎖本身不會帶來多少的性能消耗，性能主要是線上程的擷取鎖的過程。【Redis實作的分布式鎖和分布式限流】
如果隻有一個線程競争鎖，此時并不存在多線程競争的情況，那麼JVM會進行優化，那麼這時加鎖帶來的性能消耗基本可以忽略。是以，規範加鎖的操作，優化鎖的使用方法，避免不必要的線程競争，不僅可以提高程式性能，也能避免不規範加鎖可能造成線程死鎖問題，提高程式健壯性。下面闡述幾種鎖優化的思路。
一、盡量不要鎖住方法
在普通成員函數上加鎖時，線程獲得的是該方法所在對象的對象鎖。此時整個對象都會被鎖住。這也意味着，如果這個對象提供的多個同步方法是針對不同業務的，那麼由于整個對象被鎖住，一個業務業務在處理時，其他不相關的業務線程也必須wait。下面的例子展示了這種情況：
運作程式，可以看到線上程bussa 執行的過程中，bussb是不能夠進入函數 busiB()的，因為此時lockMethod 的對象鎖被線程bussa擷取了。【Git内部原理之Git對象】
二、縮小同步代碼塊，隻鎖資料
有時候為了程式設計友善，有些人會synchnoized很大的一塊代碼，如果這個代碼塊中的某些操作與共享資源并不相關，那麼應當把它們放到同步塊外部，避免長時間的持有鎖，造成其他線程一直處于等待狀态。尤其是一些循環操作、同步I/O操作。
不止是在代碼的行數範圍上縮小同步塊，在執行邏輯上，也應該縮小同步塊，例如多加一些條件判斷，符合條件的再進行同步，而不是同步之後再進行條件判斷，盡量減少不必要的進入同步塊的邏輯。
三、鎖中盡量不要再包含鎖
這種情況經常發生，線程在得到了A鎖之後，在同步方法塊中調用了另外對象的同步方法，獲得了第二個鎖，這樣可能導緻一個調用堆棧中有多把鎖的請求，多線程情況下可能會出現很複雜、難以分析的異常情況，導緻死鎖的發生。下面的代碼顯示了這種情況：【Java 程式設計中關于異常處理的 10 個最佳實踐】
四、将鎖私有化，在内部管理鎖
把鎖作為一個私有的對象，外部不能拿到這個對象，更安全一些。對象可能被其他線程直接進行加鎖操作，此時線程便持有了該對象的對象鎖，例如下面這種情況：
這種使用方式下，對象a的對象鎖被外部所持有，讓這把鎖在外部多個地方被使用是比較危險的，對代碼的邏輯流程閱讀也造成困擾。一種更好的方式是在類的内部自己管理鎖，外部需要同步方案時，也是通過接口方式來提供同步操作：
五、進行适當的鎖分解
考慮下面這段程式：
在這個例子中，join方法隻使用一個同步鎖，來擷取tables中的List對象，然後判斷玩家數量是不是小于9，如果是，就調增加一個玩家。當有成千上萬個List存在tables中時，對tables鎖的競争将非常激烈。面【試中常問的List去重問題，你都答對了嗎？】
在這裡，我們可以考慮進行鎖的分解：快速取出資料之後，對List對象進行加鎖，讓其他線程可快速競争獲得tables對象鎖：
擴充閱讀
來源：https://www.cnblogs.com/QG-whz/p/8351298.html