首先加鎖會帶來效能上的損壞，但是加鎖本身不會帶來多少效能消耗，效能消耗主要是在獲取鎖的過程。如果只有一個執行緒競爭鎖，此時並不存在多執行緒競爭的情況，那麼 JVM 會進行優化，這時加鎖帶來的效能消耗基本可以忽略。因此，優化鎖的使用可以避免不必要的執行緒競爭，不僅可以提高程式效能，也能避免不規範加鎖可能造成執行緒死鎖問題，提高程式健壯性。

實踐中常見的優化策略如下：

儘量不要鎖住方法

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

縮小同步程式碼塊（只鎖資料）

有時候為了程式設計方便，有些人會 synchnoized 很大的一塊程式碼，如果這個程式碼塊中的某些操作與共享資源並不相關，那麼應當把它們放到同步塊外部，避免長時間持有鎖而造成其他執行緒一直處於等待狀態。尤其是一些迴圈操作、同步 I/O 操作。不止是在程式碼的行數範圍上縮小同步塊，在執行邏輯上，也應該縮小同步塊，例如多加一些條件判斷，符合條件的再進行同步，而不是同步之後再進行條件判斷，儘量減少不必要的進入同步塊的邏輯。

鎖中儘量不要再包含鎖

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

//錯誤示範1
synchronized(A){
   synchronized(B){
       //TODO
   }  
}

//錯誤示範2
synchronized(A){
    B  b = list.get(0);
    b.func(); //這是一個B的同步方法
}

//正確示範1
{
    B b = null;
    synchronized(A){
        b = list.get(0);
    }
    b.method(); //跳出來加鎖，不包含加鎖
}

將鎖私有化（在內部管理鎖）

把鎖作為一個私有的物件，外部不能拿到這個物件，更安全一些。物件可能被其他執行緒直接進行加鎖操作，此時執行緒便持有了該物件的物件鎖，所以推薦的做法是把 private Object lock = new Object();

進行適當的鎖分解

其實也就是鎖範圍最小化一個原則，有些場景我們的業務很複雜，為了方便大塊鎖在了一起，其實如果仔細分析是可以拆分成多段的，與其一大段被鎖著只能一個執行緒順序處理，還不如分成多個小段來提升一些效率。

選擇合適特性的鎖

譬如有些場景適合 synchnoized，有些適合 Lock 家族不同的鎖，譬如可重入鎖，互斥鎖，共享鎖，讀寫鎖等，我們要依據自己業務場景選擇適合自己特性的鎖。