本文介紹為了實作高效并發，虛拟機對 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 ** = new StringBuffer();
**.append(s1);
**.append(s2);
**.append(s3);
return **.toString();
}
現在大家還認為這段代碼沒有涉及同步嗎？每個 StringBuffer.append() 方法中都有一個同步塊，鎖就是 ** 對象。虛拟機觀察 ** 變量，經過逃逸分析後會發現它的動态作用域被限制在 concatString() 方法内部。也就是 ** 的所有引用都永遠不會逃逸到 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 釋放鎖的同時，喚醒被挂起的線程。被喚醒的線程就會進行新一輪的競争，嘗試擷取這個鎖。
為幫助開發者們提升面試技能、有機會入職BATJ等大廠公司，特别制作了這個專輯——這一次整體放出。
大緻内容包括了： Java 集合、JVM、多線程、并發程式設計、設計模式、Spring全家桶、Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、MongoDB、Redis、MySQL、RabbitMQ、Kafka、Linux、Netty、Tomcat等大廠面試題等、等技術棧！
歡迎大家關注公衆号【Java爛豬皮】，回複【666】，擷取以上最新Java後端架構VIP學習資料以及視訊學習教程，然後一起學習，一文在手，面試我有。
每一個專欄都是大家非常關心，和非常有價值的話題，如果我的文章對你有所幫助，還請幫忙點贊、好評、轉發一下，你的支援會激勵我輸出更高品質的文章，非常感謝！