在C程式程式碼中我們可以利用作業系統提供的互斥鎖來實現同步塊的互斥訪問及執行緒的阻塞及喚醒等工作。然而在Java中除了提供Lock API外還在語法層面上提供了synchronized關鍵字來實現互斥同步原語。那麼到底在JVM內部是怎麼實現synchronized關鍵子的呢？

一、synchronized的位元組碼錶示： 

      在java語言中存在兩種內建的synchronized語法：1、synchronized語句；2、synchronized方法。對於synchronized語句當Java原始碼被javac編譯成bytecode的時候，會在同步塊的入口位置和退出位置分別插入

二、JVM中鎖的優化：

      簡單來說在JVM中monitorenter和monitorexit位元組碼依賴於底層的作業系統的Mutex Lock來實現的，但是由於使用Mutex Lock需要將當前執行緒掛起並從使用者態切換到核心態來執行，這種切換的代價是非常昂貴的；然而在現實中的大部分情況下，同步方法是執行在單執行緒環境（無鎖競爭環境）如果每次都呼叫Mutex Lock那麼將嚴重的影響程式的效能。不過在jdk1.6中對鎖的實現引入了大量的優化，如鎖粗化（Lock Coarsening）、鎖消除（Lock Elimination）、輕量級鎖（Lightweight Locking）、偏向鎖（Biased Locking）、適應性自旋（Adaptive Spinning）等技術來減少鎖操作的開銷。

鎖粗化（Lock Coarsening）： 也就是減少不必要的緊連在一起的unlock，lock操作，將多個連續的鎖擴充套件成一個範圍更大的鎖。

鎖消除（Lock Elimination）： 通過執行時JIT編譯器的逃逸分析來消除一些沒有在當前同步塊以外被其他執行緒共享的資料的鎖保護，通過逃逸分析也可以線上程本地Stack上進行物件空間的分配（同時還可以減少Heap上的垃圾收集開銷）。

輕量級鎖（Lightweight Locking）： 這種鎖實現的背後基於這樣一種假設，即在真實的情況下我們程式中的大部分同步程式碼一般都處於無鎖競爭狀態（即單執行緒執行環境），在無鎖競爭的情況下完全可以避免呼叫作業系統層面的重量級互斥鎖，取而代之的是在monitorenter和monitorexit中只需要依靠一條CAS原子指令就可以完成鎖的獲取及釋放。當存在鎖競爭的情況下，執行CAS指令失敗的執行緒將呼叫作業系統互斥鎖進入到阻塞狀態，當鎖被釋放的時候被喚醒（具體處理步驟下面詳細討論）。

偏向鎖（Biased Locking）： 是為了在無鎖競爭的情況下避免在鎖獲取過程中執行不必要的CAS原子指令，因為CAS原子指令雖然相對於重量級鎖來說開銷比較小但還是存在非常可觀的本地延遲（可參考這篇 文章 ）。

適應性自旋（Adaptive Spinning）： 當執行緒在獲取輕量級鎖的過程中執行CAS操作失敗時，在進入與monitor相關聯的作業系統重量級鎖（mutex semaphore）前會進入忙等待（Spinning）然後再次嘗試，當嘗試一定的次數後如果仍然沒有成功則呼叫與該monitor關聯的semaphore（即互斥鎖）進入到阻塞狀態。

三、物件頭（Object Header）：

在JVM中建立物件時會在物件前面加上兩個字大小的物件頭，在32位機器上一個字為32bit，根據不同的狀態位Mark World中存放不同的內容，如上圖所示在輕量級鎖中，Mark Word被分成兩部分，剛開始時LockWord為被設定為HashCode、最低三位表示LockWord所處的狀態，初始狀態為001表示無鎖狀態。Klass ptr指向Class位元組碼在虛擬機器內部的物件表示的地址。Fields表示連續的物件例項欄位。

四、Monitor Record：

 Monitor Record是執行緒私有的資料結構，每一個執行緒都有一個可用monitor record列表，同時還有一個全域性的可用列表；那麼這些monitor record有什麼用呢？每一個被鎖住的物件都會和一個monitor record關聯（物件頭中的LockWord指向monitor record的起始地址，由於這個地址是8byte對齊的所以LockWord的最低三位可以用來作為狀態位），同時monitor record中有一個Owner欄位存放擁有該鎖的執行緒的唯一標識，表示該鎖被這個執行緒佔用。如下圖所示為Monitor Record的內部結構： 

Owner：初始時為NULL表示當前沒有任何執行緒擁有該monitor record，當執行緒成功擁有該鎖後儲存執行緒唯一標識，當鎖被釋放時又設定為NULL；

EntryQ:關聯一個系統互斥鎖（semaphore），阻塞所有試圖鎖住monitor record失敗的執行緒。

RcThis:表示blocked或waiting在該monitor record上的所有執行緒的個數。

Nest:用來實現重入鎖的計數。

HashCode:儲存從物件頭拷貝過來的HashCode值（可能還包含GC age）。

Candidate:用來避免不必要的阻塞或等待執行緒喚醒，因為每一次只有一個執行緒能夠成功擁有鎖，如果每次前一個釋放鎖的執行緒喚醒所有正在阻塞或等待的執行緒，會引起不必要的上下文切換（從阻塞到就緒然後因為競爭鎖失敗又被阻塞）從而導致效能嚴重下降。Candidate只有兩種可能的值0表示沒有需要喚醒的執行緒1表示要喚醒一個繼任執行緒來競爭鎖。

五、輕量級鎖具體實現：

 一個執行緒能夠通過兩種方式鎖住一個物件：1、通過膨脹一個處於無鎖狀態（狀態位001）的物件獲得該物件的鎖；2、物件已經處於膨脹狀態（狀態位00）但LockWord指向的monitor record的Owner欄位為NULL，則可以直接通過CAS原子指令嘗試將Owner設定為自己的標識來獲得鎖。

獲取鎖（monitorenter）的大概過程如下：

（1）當物件處於無鎖狀態時（RecordWord值為HashCode，狀態位為001），執行緒首先從自己的可用moniter record列表中取得一個空閒的moniter record，初始Nest和Owner值分別被預先設定為1和該執行緒自己的標識，一旦monitor record準備好然後我們通過CAS原子指令安裝該monitor record的起始地址到物件頭的LockWord欄位來膨脹(原文為inflate，我覺得之所以叫inflate主要是由於當物件被膨脹後擴充套件了物件的大小；為了空間效率，將monitor record結構從物件頭中抽出去，當需要的時候才將該結構attach到物件上，但是和這篇 Paper 有點互相矛盾，兩種實現方式稍微有點不同)該物件，如果存在其他執行緒競爭鎖的情況而呼叫CAS失敗，則只需要簡單的回到monitorenter重新開始獲取鎖的過程即可。 

（2）物件已經被膨脹同時Owner中儲存的執行緒標識為獲取鎖的執行緒自己，這就是重入（reentrant）鎖的情況，只需要簡單的將Nest加1即可。不需要任何原子操作，效率非常高。

（3）物件已膨脹但Owner的值為NULL，當一個鎖上存在阻塞或等待的執行緒同時鎖的前一個擁有者剛釋放鎖時會出現這種狀態，此時多個執行緒通過CAS原子指令在多執行緒競爭狀態下試圖將Owner設定為自己的標識來獲得鎖，競爭失敗的執行緒在則會進入到第四種情況（4）的執行路徑。

（4）物件處於膨脹狀態同時Owner不為NULL(被鎖住)，在呼叫作業系統的重量級的互斥鎖之前先自旋一定的次數，當達到一定的次數時如果仍然沒有成功獲得鎖，則開始準備進入阻塞狀態，首先將rfThis的值原子性的加1，由於在加1的過程中可能會被其他執行緒破壞Object和monitor record之間的關聯，所以在原子性加1後需要再進行一次比較以確保LockWord的值沒有被改變，當發現被改變後則要重新進行monitorenter過程。同時再一次觀察Owner是否為NULL，如果是則呼叫CAS參與競爭鎖，鎖競爭失敗則進入到阻塞狀態。

釋放鎖（monitorexit）的大概過程如下：

（1）首先檢查該物件是否處於膨脹狀態並且該執行緒是這個鎖的擁有者，如果發現不對則丟擲異常；

（2）檢查Nest欄位是否大於1，如果大於1則簡單的將Nest減1並繼續擁有鎖，如果等於1，則進入到（3）；

（3）檢查rfThis是否大於0，設定Owner為NULL然後喚醒一個正在阻塞或等待的執行緒再一次試圖獲取鎖，如果等於0則進入到（4）

（4）縮小（deflate）一個物件，通過將物件的LockWord置換回原來的HashCode值來解除和monitor record之間的關聯來釋放鎖，同時將monitor record放回到執行緒是有的可用monitor record列表。