問題背景
Synchronized是通過對象內部的一個叫做監視器鎖（monitor）來實現的。但是監視器鎖本質又是依賴於底層的操作系統的Mutex Lock來實現的。而操作系統實現線程之間的切換這就需要從用戶態轉換到核心態，這個成本非常高，狀態之間的轉換需要相對比較長的時間，這就是爲什麼Synchronized效率低的原因。因此，這種依賴於操作系統Mutex Lock所實現的鎖我們稱之爲“重量級鎖”。JDK中對Synchronized做的種種優化，其核心都是爲了減少這種重量級鎖的使用。JDK1.6以後，爲了減少獲得鎖和釋放鎖所帶來的性能消耗，提高性能，引入了“輕量級鎖”和“偏向鎖”。
鎖的狀態
鎖的狀態總共有四種：無鎖狀態、偏向鎖、輕量級鎖和重量級鎖。隨着鎖的競爭，鎖可以從偏向鎖升級到輕量級鎖，再升級的重量級鎖（但是鎖的升級是單向的，也就是說只能從低到高升級，不會出現鎖的降級）。JDK 1.6中默認是開啓偏向鎖和輕量級鎖的，我們也可以通過-XX:-UseBiasedLocking來禁用偏向鎖。鎖的狀態保存在對象的頭文件中，以32位的JDK爲例：
輕量級鎖
“輕量級”是相對於使用操作系統互斥量來實現的傳統鎖而言的。但是，首先需要強調一點的是，輕量級鎖並不是用來代替重量級鎖的，它的本意是在沒有多線程競爭的前提下，減少傳統的重量級鎖使用產生的性能消耗。在解釋輕量級鎖的執行過程之前，先明白一點，輕量級鎖所適應的場景是線程交替執行同步塊的情況，如果存在同一時間訪問同一鎖的情況，就會導致輕量級鎖膨脹爲重量級鎖。
1、輕量級鎖的加鎖過程
（1）在代碼進入同步塊的時候，如果同步對象鎖狀態爲無鎖狀態（鎖標誌位爲“01”狀態，是否爲偏向鎖爲“0”），虛擬機首先將在當前線程的棧幀中建立一個名爲鎖記錄（Lock Record）的空間，用於存儲鎖對象目前的Mark Word的拷貝，官方稱之爲 Displaced Mark Word。這時候線程堆棧與對象頭的狀態如圖2.1所示。
圖2.1 輕量級鎖CAS操作之前堆棧與對象的狀態
（2）拷貝對象頭中的Mark Word複製到鎖記錄中。
（3）拷貝成功後，虛擬機將使用CAS操作嘗試將對象的Mark Word更新爲指向Lock Record的指針，並將Lock record裏的owner指針指向object mark word。如果更新成功，則執行步驟（4），如果這個更新操作失敗, 執行步驟（5）。
（4）如果這個更新動作成功了，那麼這個線程就擁有了該對象的鎖，並且對象Mark Word的鎖標誌位設置爲“00”，即表示此對象處於輕量級鎖定狀態，這時候線程堆棧與對象頭的狀態如圖2.2所示。
圖2.2 輕量級鎖CAS操作之後堆棧與對象的狀態
（5）如果這個更新操作失敗了，虛擬機首先會檢查對象的Mark Word是否指向當前線程的棧幀，如果是就說明當前線程已經擁有了這個對象的鎖，那就可以直接進入同步塊繼續執行。否則說明多個線程競爭鎖，輕量級鎖就要膨脹爲重量級鎖，鎖標誌的狀態值變爲“10”，Mark Word中存儲的就是指向重量級鎖（互斥量）的指針，後面等待鎖的線程也要進入阻塞狀態。而當前線程便嘗試使用自旋來獲取鎖，自旋就是爲了不讓線程阻塞，而採用循環去獲取鎖的過程。
2、輕量級鎖的解鎖過程：
（1）通過CAS操作嘗試把線程中複製的Displaced Mark Word對象替換當前的Mark Word。
（2）如果替換成功，整個同步過程就完成了。
（3）如果替換失敗，說明有其他線程嘗試過獲取該鎖（此時鎖已膨脹），那就要在釋放鎖的同時，喚醒被掛起的線程。
偏向鎖
引入偏向鎖是爲了在無多線程競爭的情況下儘量減少不必要的輕量級鎖執行路徑，因爲輕量級鎖的獲取及釋放依賴多次CAS原子指令，而偏向鎖只需要在置換ThreadID的時候依賴一次CAS原子指令（由於一旦出現多線程競爭的情況就必須撤銷偏向鎖，所以偏向鎖的撤銷操作的性能損耗必須小於節省下來的CAS原子指令的性能消耗）。上面說過，輕量級鎖是爲了在線程交替執行同步塊時提高性能，而偏向鎖則是在只有一個線程執行同步塊時進一步提高性能。
1、偏向鎖獲取過程：
（1）訪問Mark Word中偏向鎖的標識是否設置成1，鎖標誌位是否爲01——確認爲可偏向狀態。
（2）如果爲可偏向狀態，則測試線程ID是否指向當前線程，如果是，進入步驟（5），否則進入步驟（3）。
（3）如果線程ID並未指向當前線程，則通過CAS操作競爭鎖。如果競爭成功，則將Mark Word中線程ID設置爲當前線程ID，然後執行（5）；如果競爭失敗，執行（4）。
（4）如果CAS獲取偏向鎖失敗，則表示有競爭。當到達全局安全點（safepoint）時獲得偏向鎖的線程被掛起，偏向鎖升級爲輕量級鎖，然後被阻塞在安全點的線程繼續往下執行同步代碼。
（5）執行同步代碼。
2、偏向鎖的釋放：
偏向鎖的撤銷在上述第四步驟中有提到。偏向鎖只有遇到其他線程嘗試競爭偏向鎖時，持有偏向鎖的線程纔會釋放鎖，線程不會主動去釋放偏向鎖。偏向鎖的撤銷，需要等待全局安全點（在這個時間點上沒有字節碼正在執行），它會首先暫停擁有偏向鎖的線程，判斷鎖對象是否處於被鎖定狀態，撤銷偏向鎖後恢復到未鎖定（標誌位爲“01”）或輕量級鎖（標誌位爲“00”）的狀態。
3、重量級鎖、輕量級鎖和偏向鎖之間轉換
JVM 鎖的其他優化
1、適應性自旋（Adaptive Spinning）：
從輕量級鎖獲取的流程中我們知道，當線程在獲取輕量級鎖的過程中執行CAS操作失敗時，是要通過自旋來獲取重量級鎖的。問題在於，自旋是需要消耗CPU的，如果一直獲取不到鎖的話，那該線程就一直處在自旋狀態，白白浪費CPU資源。解決這個問題最簡單的辦法就是指定自旋的次數，例如讓其循環10次，如果還沒獲取到鎖就進入阻塞狀態。但是JDK採用了更聰明的方式——適應性自旋，簡單來說就是線程如果自旋成功了，則下次自旋的次數會更多，如果自旋失敗了，則自旋的次數就會減少。
2、鎖粗化（Lock Coarsening）：
鎖粗化的概念應該比較好理解，就是將多次連接在一起的加鎖、解鎖操作合併爲一次，將多個連續的鎖擴展成一個範圍更大的鎖。舉個例子：
package com.paddx.test.string;
public class StringBufferTest {
StringBuffer stringBuffer = new StringBuffer();
public void append(){
stringBuffer.append("a");
stringBuffer.append("b");
stringBuffer.append("c");
}
}
這裏每次調用stringBuffer.append方法都需要加鎖和解鎖，如果虛擬機檢測到有一系列連串的對同一個對象加鎖和解鎖操作，就會將其合併成一次範圍更大的加鎖和解鎖操作，即在第一次append方法時進行加鎖，最後一次append方法結束後進行解鎖。
3、鎖消除（Lock Elimination）：
鎖消除即刪除不必要的加鎖操作。根據代碼逃逸技術，如果判斷到一段代碼中，堆上的數據不會逃逸出當前線程，那麼可以認爲這段代碼是線程安全的，不必要加鎖。看下面這段程序：
package com.paddx.test.concurrent;
public class SynchronizedTest02 {
public static void main(String[] args) {
SynchronizedTest02 test02 = new SynchronizedTest02();
//啓動預熱
for (int i = 0; i < 10000; i++) {
i++;
}
long start = System.currentTimeMillis();
for (int i = 0; i < 100000000; i++) {
test02.append("abc", "def");
}
System.out.println("Time=" + (System.currentTimeMillis() - start));
}
public void append(String str1, String str2) {
StringBuffer sb = new StringBuffer();
sb.append(str1).append(str2);
}
}
雖然StringBuffer的append是一個同步方法，但是這段程序中的StringBuffer屬於一個局部變量，並且不會從該方法中逃逸出去，所以其實這過程是線程安全的，可以將鎖消除。
總結
本文重點介紹了JDK 中採用輕量級鎖和偏向鎖等對Synchronized的優化，但是這兩種鎖也不是完全沒缺點的，比如競爭比較激烈的時候，不但無法提升效率，反而會降低效率，因爲多了一個鎖升級的過程，這個時候就需要通過-XX:-UseBiasedLocking來禁用偏向鎖。
下面是這幾種鎖的對比：
參考資料
https://www.cnblogs.com/paddix/p/5405678.html
http://www.iteye.com/topic/1018932
http://www.infoq.com/cn/articles/java-se-16-synchronized
http://frank1234.iteye.com/blog/2163142
https://www.artima.com/insidejvm/ed2/threadsynch3.html
http://www.tuicool.com/articles/2aeAZn
Kotlin開發者社區
專注分享 Java、 Kotlin、Spring/Spring Boot、MySQL、redis、neo4j、NoSQL、Android、JavaScript、React、Node、函數式編程、編程思想、"高可用，高性能，高實時"大型分佈式系統架構設計主題。
High availability, high performance, high real-time large-scale distributed system architecture design。
分佈式框架：Zookeeper、分佈式中間件框架等
分佈式存儲：GridFS、FastDFS、TFS、MemCache、redis等
分佈式數據庫：Cobar、tddl、Amoeba、Mycat
雲計算、大數據、AI算法
虛擬化、雲原生技術
分佈式計算框架：MapReduce、Hadoop、Storm、Flink等
分佈式通信機制：Dubbo、RPC調用、共享遠程數據、消息隊列等
消息隊列MQ：Kafka、MetaQ，RocketMQ
怎樣打造高可用系統：基於硬件、軟件中間件、系統架構等一些典型方案的實現：HAProxy、基於Corosync+Pacemaker的高可用集羣套件中間件系統
Mycat架構分佈式演進
大數據Join背後的難題：數據、網絡、內存和計算能力的矛盾和調和
Java分佈式系統中的高性能難題：AIO，NIO，Netty還是自己開發框架？
高性能事件派發機制：線程池模型、Disruptor模型等等。。。
合抱之木，生於毫末；九層之臺，起於壘土；千里之行，始於足下。不積跬步，無以至千里；不積小流，無以成江河。