本文介紹為了實作高效并發，虛擬機對 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

標籤：其他

上一篇：python中set和frozenset方法和區別

下一篇：返回列表