本文介紹為了實現高效並行，虛擬機器器對 synchronized 做的一系列的鎖優化措施

高效並行是從 JDK5 升級到 JDK6 後一項重要的改進項，HotSpot 虛擬機器器開發團隊在 JDK6 這個版本上花費了大量的資源去實現各種鎖優化技術，如適應性自旋（Adaptive Spinning）、鎖消除（Lock Elimination）、鎖膨脹（Lock Coarsening）、輕量級鎖（Lightweight Locking）、偏向鎖（Biased Locking）等，這些技術都是為了線上程之間更高效地共用資料及解決競爭問題，從而提高程式的執行效率。

自旋鎖 & 自適應自旋

在許多應用上，共用資料的鎖定狀態只會持續很短的一段時間，為了這段時間去掛起和恢復執行緒並不值得。

自旋鎖指的是：執行緒 A 成功獲取鎖後，執行緒 B 請求鎖時，請求鎖的執行緒 B 執行一個忙迴圈（自旋），不放棄處理器的執行時間，看看持有鎖的執行緒 A 是否會很快就釋放鎖。自旋等待的時間有一定的限度，如果自旋超過了限定的次數仍然沒有成功獲得鎖，就應當使用傳統的方式去掛起執行緒。

自適應自旋指的是：自旋的時間不再是固定的了，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定的。

前面我們討論互斥同步的時候，提到了互斥同步對效能影響最大的是阻塞的實現，掛起執行緒和恢復執行緒的操作都需要轉入核心態中完成，這些操作給Java虛擬機器器的並行效能帶來了很大的壓力。同時，虛擬機器器的開發團隊也注意到在許多應用上，共用資料的鎖定狀態只會持續很短的一段時間，為了這段時間去掛起和恢復執行緒並不值得。現在絕大多數的個人電腦和伺服器都是多路（核）處理器系統，如果物理機器有一個以上的處理器或者處理器核心，能讓兩個或以上的執行緒同時並行執行，我們就可以讓後面請求鎖的那個執行緒「稍等一會」，但不放棄處理器的執行時間，看看持有鎖的執行緒是否很快就會釋放鎖。為了讓執行緒等待，我們只須讓執行緒執行一個忙迴圈（自旋），這項技術就是所謂的自旋鎖。

自旋鎖在 JDK1.4.2 中就已經引入，只不過預設是關閉的，可以使用 -XX：+UseSpinning 引數來開啟，在 JDK6 中就已經改為預設開啟了。自旋等待不能代替阻塞，且先不說對處理器數量的要求，自旋等待本身雖然避免了執行緒切換的開銷，但它是要佔用處理器時間的，所以如果鎖被佔用的時間很短，自旋等待的效果就會非常好，反之如果鎖被佔用的時間很長，那麼自旋的執行緒只會白白消耗處理器資源，而不會做任何有價值的工作，這就會帶來效能的浪費。因此自旋等待的時間必須有一定的限度，如果自旋超過了限定的次數仍然沒有成功獲得鎖，就應當使用傳統的方式去掛起執行緒。自旋次數的預設值是十次，使用者也可以使用引數 -XX：PreBlockSpin 來自行更改。

不過無論是預設值還是使用者指定的自旋次數，對整個 Java 虛擬機器器中所有的鎖來說都是相同的。在 JDK6 中對自旋鎖的優化，引入了自適應的自旋。自適應意味著自旋的時間不再是固定的了，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定的。

如果在同一個鎖物件上，自旋等待剛剛成功獲得過鎖，並且持有鎖的執行緒正在執行中，那麼虛擬機器器就會認為這次自旋也很有可能再次成功，進而允許自旋等待持續相對更長的時間，比如持續100次忙迴圈。
另一方面，如果對於某個鎖，自旋很少成功獲得過鎖，那在以後要獲取這個鎖時將有可能直接省略掉自旋過程，以避免浪費處理器資源。

有了自適應自旋，隨著程式執行時間的增長及效能監控資訊的不斷完善，虛擬機器器對程式鎖的狀況預測就會越來越精準，虛擬機器器就會變得越來越「聰明」了。

鎖消除

鎖消除是指虛擬機器器即時編譯器在執行時，對一些程式碼要求同步，但是被檢測到不可能存在共用資料競爭的鎖進行消除。鎖消除的主要判定依據來源於逃逸分析的資料支援，如果判斷到一段程式碼中，在堆上的所有資料都不會逃逸出去被其他執行緒存取到，那就可以把它們當作棧上資料對待，認為它們是執行緒私有的，同步加鎖自然就無須再進行。

也許讀者會有疑問，變數是否逃逸，對於虛擬機器器來說是需要使用複雜的過程間分析才能確定的，但是程式設計師自己應該是很清楚的，怎麼會在明知道不存在資料爭用的情況下還要求同步呢？這個問題的答案是：有許多同步措施並不是程式設計師自己加入的，同步的程式碼在 Java 程式中出現的頻繁程度也許超過了大部分讀者的想象。我們來看看如程式碼清單13-6所示的例子，這段非常簡單的程式碼僅僅是輸出三個字串相加的結果，無論是原始碼字面上，還是程式語意上都沒有進行同步。

// 程式碼清單13-6 一段看起來沒有同步的程式碼
public String concatString(String s1, String s2, String s3) {
    return s1 + s2 + s3;
}

我們也知道，由於 String 是一個不可變的類，對字串的連線操作總是通過生成新的 String 物件來進行的，因此 Javac 編譯器會對 String 連線做自動優化。

在 JDK5 之前，字串加法會轉化為 StringBuffer 物件的連續 append() 操作。即程式碼清單13-6所示的程式碼可能會變成程式碼清單13-7所示的樣子。
在 JDK5 及以後的版本中，會轉化為 StringBuilder 物件的連續 append() 操作。

// 程式碼清單13-7 Javac轉化後的字串連線操作
public String concatString(String s1, String s2, String s3) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    sb.append(s3);
    return sb.toString();
}

現在大家還認為這段程式碼沒有涉及同步嗎？每個 StringBuffer.append() 方法中都有一個同步塊，鎖就是 sb 物件。虛擬機器器觀察 sb 變數，經過逃逸分析後會發現它的動態作用域被限制在 concatString() 方法內部。也就是 sb 的所有參照都永遠不會逃逸到 concatString() 方法之外，其他執行緒無法存取到它，所以這裡雖然有鎖，但是可以被安全地消除掉。在解釋執行時這裡仍然會加鎖，但在經過伺服器端編譯器的即時編譯之後，這段程式碼就會忽略所有的同步措施而直接執行。

鎖粗化

鎖粗化指的是：如果虛擬機器器探測到有一串零碎的操作都對同一個物件加鎖，那麼虛擬機器器將會把加鎖同步的範圍擴充套件（粗化）到整個操作序列的外部。

原則上，我們在編寫程式碼的時候，總是推薦將同步塊的作用範圍限制得儘量小：只在共用資料的實際作用域中才進行同步，這樣是為了使得需要同步的運算元量儘可能變少，即使存在鎖競爭，等待鎖的執行緒也能儘可能快地拿到鎖。

大多數情況下，上面的原則都是正確的，但是如果一系列的連續操作都對同一個物件反覆加鎖和解鎖，甚至加鎖操作是出現在迴圈體之中的，那即使沒有執行緒競爭，頻繁地進行互斥同步操作也會導致不必要的效能損耗。

程式碼清單13-7所示連續的 append() 方法就屬於這類情況。如果虛擬機器器探測到有這樣一串零碎的操作都對同一個物件加鎖，將會把加鎖同步的範圍擴充套件（粗化）到整個操作序列的外部，以程式碼清單13-7為例，就是擴充套件到第一個 append() 操作之前直至最後一個 append() 操作之後，這樣只需要加鎖一次就可以了。

輕量級鎖

輕量級鎖的設計初衷是在沒有多執行緒競爭的情況下，通過使用 CAS（Compare And Swap）操作來進行執行緒同步，減少傳統的重量級鎖使用作業系統互斥量產生的效能消耗。

輕量級鎖可以提高帶有同步但無競爭的程式效能，但它是一個帶有效益權衡（Trade Off）性質的優化，也就是說它並非總是對程式執行有利。輕量級鎖能提升程式同步效能的依據是「對於絕大部分的鎖，在整個同步週期內都是不存在競爭的」這一經驗法則。

如果沒有競爭，輕量級鎖便通過 CAS 操作成功避免了使用互斥量的開銷；

但如果確實存在鎖競爭，除了互斥量的本身開銷外，還額外發生了 CAS 操作的開銷。

因此在有競爭的情況下，輕量級鎖反而會比傳統的重量級鎖更慢。

輕量級鎖是 JDK6 時加入的新型鎖機制，它名字中的「輕量級」是相對於使用作業系統互斥量來實現的傳統鎖而言的，因此傳統的鎖機制就被稱為「重量級」鎖。不過，需要強調一點，輕量級鎖並不是用來代替重量級鎖的，輕量級鎖設計的初衷是在沒有多執行緒競爭的前提下，減少傳統的重量級鎖使用作業系統互斥量產生的效能消耗。

Mark Word

要理解輕量級鎖，以及後面會講到的偏向鎖的原理和運作過程，必須要對 HotSpot 虛擬機器器物件的記憶體佈局（尤其是物件頭部分）有所瞭解。HotSpot 虛擬機器器的物件頭（Object Header）分為兩部分：

第一部分用於儲存物件自身的執行時資料，如雜湊碼（HashCode）、GC 分代年齡（Generational GC Age）等。這部分資料的長度在 32 位和 64 位的 Java 虛擬機器器中分別會佔用 32 個或 64 個位元，官方稱它為「Mark Word」。這部分是實現輕量級鎖和偏向鎖的關鍵。
另外一部分用於儲存指向方法區物件型別資料的指標（Class Pointer、型別指標），虛擬機器器通過這個指標來確定這個物件是哪個類的範例。如果是陣列物件，還會有一個額外的部分用於儲存陣列長度。

由於物件頭資訊是與物件自身定義的資料無關的額外儲存成本，考慮到 Java 虛擬機器器的空間使用效率，Mark Word 被設計成一個非固定的動態資料結構，以便在極小的空間記憶體儲儘量多的資訊。它會根據物件的狀態複用自己的儲存空間。例如在 32 位的 HotSpot 虛擬機器器中：

物件未被鎖定的狀態下，Mark Word 的 32 個位元空間裡的 25 個位元將用於儲存物件雜湊碼，4 個位元用於儲存物件分代年齡，2 個位元用於儲存鎖標誌位，還有 1 個位元固定為 0（這表示未進入偏向模式）。
物件除了未被鎖定的正常狀態外，還有輕量級鎖定、重量級鎖定、GC 標記、可偏向等幾種不同狀態，這些狀態下物件頭的儲存內容如下表所示。

工作過程

我們簡單回顧了物件的記憶體佈局後，接下來就可以介紹輕量級鎖的工作過程了：在程式碼即將進入同步塊的時候，如果此同步物件沒有被鎖定（鎖標誌位為「01」狀態），虛擬機器器首先將在當前執行緒的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用於儲存鎖物件目前的 Mark Word 的拷貝（官方為這份拷貝加了一個 Displaced 字首，即 Displaced Mark Word），這時候執行緒堆疊與物件頭的狀態如圖13-3所示。

圖13-3輕量級鎖 CAS 操作之前堆疊與物件的狀態

然後，虛擬機器器將使用 CAS 操作嘗試把物件的 Mark Word 更新為指向鎖記錄（Lock Record）的指標。

如果這個更新操作成功了，即代表該執行緒擁有了這個物件的鎖，並且物件 Mark Word 的鎖標誌位（Mark Word 的最後兩個位元）將轉變為「00」，表示此物件處於輕量級鎖定狀態。這時候執行緒堆疊與物件頭的狀態如圖13-4所示。
如果這個更新操作失敗了，那就意味著至少存在一條執行緒與當前執行緒競爭獲取該物件的鎖。虛擬機器器首先會檢查物件的 Mark Word 是否指向當前執行緒的棧幀，如果是，說明當前執行緒已經擁有了這個物件的鎖，那直接進入同步塊繼續執行就可以了，否則（物件的 Mark Word 不是指向當前執行緒的棧幀）就說明這個鎖物件已經被其他執行緒搶佔了。如果出現兩條以上的執行緒爭用同一個鎖的情況，那輕量級鎖就不再有效，必須要膨脹為重量級鎖，鎖標誌的狀態值變為「10」，此時 Mark Word 中儲存的就是指向重量級鎖（互斥量）的指標，後面等待鎖的執行緒也必須進入阻塞狀態。

圖13-4輕量級鎖 CAS 操作之後堆疊與物件的狀態

上面描述的是輕量級鎖的加鎖過程，它的解鎖過程也同樣是通過 CAS 操作來進行的，如果物件的 Mark Word 仍然指向執行緒的鎖記錄，那就用 CAS 操作把物件當前的 Mark Word 和執行緒中複製的 Displaced Mark Word 替換回來。

假如能夠替換成功，那整個同步過程就順利完成了；
如果替換失敗，則說明有其他執行緒嘗試過獲取該鎖，就要在釋放鎖的同時，喚醒被掛起的執行緒。

輕量級鎖能提升程式同步效能的依據是「對於絕大部分的鎖，在整個同步週期內都是不存在競爭的」這一經驗法則。

如果沒有競爭，輕量級鎖便通過 CAS 操作成功避免了使用互斥量的開銷；
但如果確實存在鎖競爭，除了互斥量的本身開銷外，還額外發生了 CAS 操作的開銷。

因此在有競爭的情況下，輕量級鎖反而會比傳統的重量級鎖更慢。

偏向鎖

偏向鎖的目的是：消除資料在無競爭情況下的同步原語，進一步提高程式的執行效能。

偏向鎖中的「偏」的意思是這個鎖會偏向於第一個獲得它的執行緒。如果虛擬機器器啟用了偏向鎖，那麼當鎖物件第一次被執行緒獲取的時候，虛擬機器器將會把物件頭中的標誌位設定為「01」、把偏向模式設定為「1」，表示進入偏向模式。同時使用 CAS 操作把獲取到這個鎖的執行緒的 ID 記錄在物件的 Mark Word 之中。如果 CAS 操作成功，持有偏向鎖的執行緒以後每次進入這個鎖相關的同步塊時，虛擬機器器都可以不再進行任何同步操作（例如加鎖、解鎖及對 Mark Word 的更新操作等）。

偏向鎖可以提高帶有同步但無競爭的程式效能，但它同樣是一個帶有效益權衡（Trade Off）性質的優化，也就是說它並非總是對程式執行有利。如果程式中大多數的鎖都總是被多個不同的執行緒存取，那偏向模式就是多餘的。

偏向鎖也是 JDK6 中引入的一項鎖優化措施，它的目的是消除資料在無競爭情況下的同步原語，進一步提高程式的執行效能。如果說輕量級鎖是在無競爭的情況下使用 CAS 操作去消除同步使用的互斥量，那偏向鎖就是在無競爭的情況下把整個同步都消除掉，連 CAS 操作都不去做了。

偏向鎖中的「偏」，就是偏心的「偏」、偏袒的「偏」。偏向鎖中的「偏」的意思是這個鎖會偏向於第一個獲得它的執行緒，如果在接下來的執行過程中，該鎖一直沒有被其他的執行緒獲取，則持有偏向鎖的執行緒將永遠不需要再進行同步。

如果讀者理解了前面輕量級鎖中關於物件頭 Mark Word 與執行緒之間的操作過程，那偏向鎖的原理就會很容易理解。

假設當前虛擬機器器啟用了偏向鎖（啟用引數 -XX：+UseBiased Locking，這是自 JDK6 起 HotSpot 虛擬機器器的預設值），那麼當鎖物件第一次被執行緒獲取的時候，虛擬機器器將會把物件頭中的標誌位設定為「01」、把偏向模式設定為「1」，表示進入偏向模式。同時使用 CAS 操作把獲取到這個鎖的執行緒的 ID 記錄在物件的 Mark Word 之中。如果 CAS 操作成功，持有偏向鎖的執行緒以後每次進入這個鎖相關的同步塊時，虛擬機器器都可以不再進行任何同步操作（例如加鎖、解鎖及對 Mark Word 的更新操作等）。

一旦出現另外一個執行緒去嘗試獲取這個鎖的情況，偏向模式就馬上宣告結束。根據鎖物件目前是否處於被鎖定的狀態決定是否復原偏向（偏向模式設定為「0」），復原後標誌位恢復到未鎖定（標誌位為「01」）或輕量級鎖定（標誌位為「00」）的狀態，後續的同步操作就按照上面介紹的輕量級鎖那樣去執行。

偏向鎖、輕量級鎖的狀態轉換及物件 Mark Word 的關係如圖13-5所示。

圖13-5偏向鎖、輕量級鎖的狀態轉換及及物件 Mark Word 的關係

細心的讀者看到這裡可能會發現一個問題：當物件進入偏向狀態的時候，Mark Word 大部分的空間（23個位元）都用於儲存持有鎖的執行緒 ID 了，這部分空間佔用了原有儲存物件雜湊碼的位置，那原來物件的雜湊碼怎麼辦呢？

在 Java 語言裡面一個物件如果計算過雜湊碼，就應該一直保持該值不變（強烈推薦但不強制，因為使用者可以過載hashCode() 方法按自己的意願返回雜湊碼），否則很多依賴物件雜湊碼的 API 都可能存在出錯風險。而作為絕大多數物件雜湊碼來源的 Object::hashCode() 方法，返回的是物件的一致性雜湊碼（Identity Hash Code），這個值是能強制保證不變的，它通過在物件頭中儲存計算結果來保證第一次計算之後，再次呼叫該方法取到的雜湊碼值永遠不會再發生改變。因此，當一個物件已經計算過一致性雜湊碼後，它就再也無法進入偏向鎖狀態了；而當一個物件當前正處於偏向鎖狀態，又收到需要計算其一致性雜湊碼請求時，它的偏向狀態會被立即復原，並且鎖會膨脹為重量級鎖。在重量級鎖的實現中，物件頭指向了重量級鎖的位置，代表重量級鎖的 ObjectMonitor 類裡有欄位可以記錄非加鎖狀態（標誌位為「01」）下的Mark Word，其中自然可以儲存原來的雜湊碼。

注意，這裡說的計算請求應來自於對Object::hashCode()或者System::identityHashCode(Object)方法的呼叫，如果重寫了物件的hashCode()方法，計算雜湊碼時並不會產生這裡所說的請求。

偏向鎖可以提高帶有同步但無競爭的程式效能，但它同樣是一個帶有效益權衡（Trade Off）性質的優化，也就是說它並非總是對程式執行有利。如果程式中大多數的鎖都總是被多個不同的執行緒存取，那偏向模式就是多餘的。在具體問題具體分析的前提下，有時候使用引數-XX：-UseBiasedLocking 來禁止偏向鎖優化反而可以提升效能。

完整的過程

假設當前虛擬機器器啟用了偏向鎖，那麼當鎖物件第一次被執行緒獲取的時候，虛擬機器器將會把物件頭中的標誌位設定為「01」、把偏向模式設定為「1」，表示進入偏向模式。同時使用 CAS 操作把獲取到這個鎖的執行緒的 ID 記錄在物件的 Mark Word 之中。如果 CAS 操作成功，持有偏向鎖的執行緒以後每次進入這個鎖相關的同步塊時，虛擬機器器都可以不再進行任何同步操作（例如加鎖、解鎖及對 Mark Word 的更新操作等）。

如果鎖物件目前處於偏向模式，那麼一旦出現另外一個執行緒去嘗試獲取這個鎖的情況，偏向模式就馬上宣告結束。根據鎖物件目前是否處於被鎖定的狀態決定復原偏向後，鎖物件處於什麼狀態。

如果鎖物件目前處於被鎖定的狀態，那麼一旦出現另外一個執行緒去嘗試獲取這個鎖的情況，偏向模式就馬上宣告結束，鎖物件轉換到輕量級鎖定狀態，後續的同步操作就按照輕量級鎖那樣去執行。
如果鎖物件目前處於未被鎖定的狀態，那麼一旦出現另外一個執行緒去嘗試獲取這個鎖的情況，偏向模式就馬上宣告結束，鎖物件轉換到未被鎖定、不可偏向狀態。

物件轉換到輕量級鎖定狀態。虛擬機器器首先將在當前執行緒的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用於儲存鎖物件目前的 Mark Word 的拷貝。然後，虛擬機器器將使用 CAS 操作嘗試把物件的 Mark Word 更新為指向鎖記錄（Lock Record）的指標。

如果這個更新操作成功了，即代表該執行緒擁有了這個物件的鎖，並且物件 Mark Word 的鎖標誌位將轉變為「00」，表示此物件處於輕量級鎖定狀態。
如果這個更新操作失敗了，那就意味著至少存在一條執行緒與當前執行緒競爭獲取該物件的鎖。虛擬機器器首先會檢查物件的 Mark Word 是否指向當前執行緒的棧幀：
- 如果是（物件的 Mark Word 指向當前執行緒的棧幀），說明當前執行緒已經擁有了這個物件的鎖，那直接進入同步塊繼續執行就可以了；
- 否則（物件的 Mark Word 不是指向當前執行緒的棧幀）就說明這個鎖物件已經被其他執行緒搶佔了，那麼當前執行緒 B 執行一個忙迴圈（自旋），不放棄處理器的執行時間，看看持有鎖的執行緒 A 是否會很快就釋放鎖。
  - 如果持有鎖的執行緒 A 很快就釋放了鎖，那麼當前執行緒 B 成功獲取鎖。
  - 如果執行緒 B 自旋超過了限定的次數仍然沒有成功獲得鎖，那輕量級鎖就不再有效，必須要膨脹為重量級鎖，鎖標誌的狀態值變為「10」，此時 Mark Word 中儲存的就是指向重量級鎖（互斥量）的指標。當前執行緒繼續等待鎖，並進入阻塞狀態。持有鎖的執行緒 A 釋放鎖的同時，喚醒被掛起的執行緒。被喚醒的執行緒就會進行新一輪的競爭，嘗試獲取這個鎖。

參考資料

第13章執行緒安全與鎖優化 13.3 鎖優化

Java中synchronized的優化