為了實現高效併發，虛擬機對 synchronized 做的一系列的鎖優化措施。包括：適應性自旋、鎖消除、鎖粗化、輕量級鎖、偏向鎖。 ...

本文介紹為了實現高效併發，虛擬機對 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 鎖優化

本文來自博客園，作者：真正的飛魚，轉載請註明原文鏈接：https://www.cnblogs.com/feiyu2/p/synchronized.html

Java中synchronized的優化