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

13.3.1 自旋鎖與自適應自旋

      前面我們討論互斥同步的時候，提到了互斥同步對效能最大的影響是阻塞的實現，掛起執行緒和恢復執行緒的操作都需要轉入核心態中完成，這些操作給系統的併發效能帶來了很大的壓力。同時，虛擬機器的開發團隊也注意到在許多應用上，共享資料的鎖定狀態只會持續很短的一段時間，為了這段時間去掛起和恢復執行緒並不值得。如果物理機器有一個以上的處理器，能讓兩個或以上的執行緒同時並行執行，我們就可以讓後面請求鎖的那個執行緒“稍等一會”，但不放棄處理器的執行時間，看看持有鎖的執行緒是否很快就會釋放鎖。為了讓執行緒等待，我們只須讓執行緒執行一個忙迴圈（自旋），這項技術就是所謂的自旋鎖。
      自旋鎖在JDK 1.4.2中就已經引入，只不過預設是關閉的，可以使用-XX:+UseSpinning引數來開啟，在JDK 1.6中就已經改為預設開啟了。自旋等待不能代替阻塞，且先不說對處理器數量的要求，自旋等待本身雖然避免了執行緒切換的開銷，但它是要佔用處理器時間的，所以如果鎖被佔用的時間很短，自旋等待的效果就會非常好，反之如果鎖被佔用的時間很長，那麼自旋的執行緒只會白白消耗處理器資源，而不會做任何有用的工作，反而會帶來效能的浪費。因此自旋等待的時間必須要有一定的限度，如果自旋超過了限定的次數仍然沒有成功獲得鎖，就應當使用傳統的方式去掛起執行緒了。自旋次數的預設值是10次，使用者可以使用引數-XX:PreBlockSpin來更改。

      在JDK 1.6中引入了自適應的自旋鎖。自適應意味著自旋的時間不再固定了，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。如果在同一個鎖物件上，自旋等待剛剛成功獲得過鎖，並且持有鎖的執行緒正在執行中，那麼虛擬機器就會認為這次自旋也很有可能再次成功，進而它將允許自旋等待持續相對更長的時間，比如100個迴圈。另一方面，如果對於某個鎖，自旋很少成功獲得過，那在以後要獲取這個鎖時將可能省略掉自旋過程，以避免浪費處理器資源。有了自適應自旋，隨著程式執行和效能監控資訊的不斷完善，虛擬機器對程式鎖的狀況預測就會越來越準確，虛擬機器就會變得越來越“聰明”了。

13.3.2 鎖削除

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

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

public String concatString(String s1, String s2, String s3) {
	return s1 + s2 + s3;
}

     我們也知道，由於String是一個不可變的類，對字串的連線操作總是通過生成新的String物件來進行的，因此Javac編譯器會對String連線做自動優化。在JDK 1.5之前，會轉化為StringBuffer物件的連續append()操作，在JDK 1.5及以後的版本中，會轉化為StringBuilder物件的連續append()操作。即程式碼清單13-6中的程式碼可能會變成程式碼清單13-7的樣子 。

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();
}
 

（注1：實事求是地說，既然談到鎖削除與逃逸分析，那虛擬機器就不可能是JDK 1.5之前的版本，所以實際上會轉化為非執行緒安全的StringBuilder來完成字串拼接，並不會加鎖。但是這也不影響筆者用這個例子證明Java物件中同步的普遍性。）

      現在大家還認為這段程式碼沒有涉及同步嗎？每個StringBuffer.append()方法中都有一個同步塊，鎖就是sb物件。虛擬機器觀察變數sb，很快就會發現它的動態作用域被限制在concatString()方法內部。也就是sb的所有引用永遠不會“逃逸”到concatString()方法之外，其他執行緒無法訪問到它，所以這裡雖然有鎖，但是可以被安全地削除掉，在即時編譯之後，這段程式碼就會忽略掉所有的同步而直接執行了。

13.3.3 鎖膨脹

     原則上，我們在編寫程式碼的時候，總是推薦將同步塊的作用範圍限制得儘量小——只在共享資料的實際作用域中才進行同步，這樣是為了使得需要同步的運算元量儘可能變小，如果存在鎖競爭，那等待鎖的執行緒也能儘快地拿到鎖。
大部分情況下，上面的原則都是正確的，但是如果一系列的連續操作都對同一個物件反覆加鎖和解鎖，甚至加鎖操作是出現在迴圈體中的，那即使沒有執行緒競爭，頻繁地進行互斥同步操作也會導致不必要的效能損耗。
      上面程式碼清單13-7中連續的append()方法就屬於這類情況。如果虛擬機器探測到有這樣一串零碎的操作都對同一個物件加鎖，將會把加鎖同步的範圍擴充套件（膨脹）到整個操作序列的外部，以程式碼清單13-7為例，就是擴充套件到第一個append()操作之前直至最後一個append()操作之後，這樣只需要加鎖一次就可以了。

13.3.4 輕量級鎖

     輕量級鎖是JDK 1.6之中加入的新型鎖機制，它名字中的“輕量級”是相對於使用作業系統互斥量來實現的傳統鎖而言的，因此傳統的鎖機制就被稱為“重量級”鎖。首先需要強調一點的是，輕量級鎖並不是用來代替重量級鎖的，它的本意是在沒有多執行緒競爭的前提下，減少傳統的重量級鎖使用作業系統互斥量產生的效能消耗。
要理解輕量級鎖，以及後面會講到的偏向鎖的原理和運作過程，必須從HotSpot虛擬機器的物件（物件頭部分）的記憶體佈局開始介紹。HotSpot虛擬機器的物件頭（Object Header）分為兩部分資訊，第一部分用於儲存物件自身的執行時資料，如雜湊碼（HashCode）、GC分代年齡（Generational GC Age）等，這部分資料的長度在32位和64位的虛擬機器中分別為32個和64個Bits，官方稱它為“Mark Word”，它是實現輕量級鎖和偏向鎖的關鍵。另外一部分用於儲存指向方法區物件型別資料的指標，如果是陣列物件的話，還會有一個額外的部分用於儲存陣列長度。
      物件頭資訊是與物件自身定義的資料無關的額外儲存成本，考慮到虛擬機器的空間效率，Mark Word被設計成一個非固定的資料結構以便在極小的空間記憶體儲儘量多的資訊，它會根據物件的狀態複用自己的儲存空間。例如在32位的HotSpot虛擬機器中物件未被鎖定的狀態下，Mark Word的32個Bits空間中的25Bits用於儲存物件雜湊碼（HashCode），4Bits用於儲存物件分代年齡，2Bits用於儲存鎖標誌位，1Bit固定為0，在其他狀態（輕量級鎖定、重量級鎖定、GC標記、可偏向）下物件的儲存內容如表13-1所示。

表13-1 HotSpot虛擬機器物件頭Mark Word

儲存內容	標誌位	狀態
物件雜湊碼、物件分代年齡	01	未鎖定
指向鎖記錄的指標	00	輕量級鎖定
指向重量級鎖的指標	10	膨脹（重量級鎖定）
空，不需要記錄資訊	11	GC標記
偏向執行緒ID、偏向時間戳、物件分代年齡	01	可偏向

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

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

     然後，虛擬機器將使用CAS操作嘗試將物件的Mark Word更新為指向Lock Record的指標。如果這個更新動作成功了，那麼這個執行緒就擁有了該物件的鎖，並且物件Mark Word的鎖標誌位（Mark Word的最後兩個Bits）將轉變為“00”，即表示此物件處於輕量級鎖定狀態，這時候執行緒堆疊與物件頭的狀態如圖13-4所示。

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

（ 注2：圖13-3和圖13-4來源於HotSpot虛擬機器的一位Senior Staff Engineer——Paul Hohensee所寫的PPT《The Hotspot Java Virtual Machine》）

      如果這個更新操作失敗了，虛擬機器首先會檢查物件的Mark Word是否指向當前執行緒的棧幀，如果是就說明當前執行緒已經擁有了這個物件的鎖，那就可以直接進入同步塊繼續執行，否則說明這個鎖物件已經被其他執行緒搶佔了。如果有兩條以上的執行緒爭用同一個鎖，那輕量級鎖就不再有效，要膨脹為重量級鎖，鎖標誌的狀態值變為“10”，Mark Word中儲存的就是指向重量級鎖（互斥量）的指標，後面等待鎖的執行緒也要進入阻塞狀態。
上面描述的是輕量級鎖的加鎖過程，它的解鎖過程也是通過CAS操作來進行的，如果物件的Mark Word仍然指向著執行緒的鎖記錄，那就用CAS操作把物件當前的Mark Word和執行緒中複製的Displaced Mark Word替換回來，如果替換成功，整個同步過程就完成了。如果替換失敗，說明有其他執行緒嘗試過獲取該鎖，那就要在釋放鎖的同時，喚醒被掛起的執行緒。
      輕量級鎖能提升程式同步效能的依據是“對於絕大部分的鎖，在整個同步週期內都是不存在競爭的”，這是一個經驗資料。如果沒有競爭，輕量級鎖使用CAS操作避免了使用互斥量的開銷，但如果存在鎖競爭，除了互斥量的開銷外，還額外發生了CAS操作，因此在有競爭的情況下，輕量級鎖會比傳統的重量級鎖更慢。

13.3.5 偏向鎖

      偏向鎖也是JDK 1.6中引入的一項鎖優化，它的目的是消除資料在無競爭情況下的同步原語，進一步提高程式的執行效能。如果說輕量級鎖是在無競爭的情況下使用CAS操作去消除同步使用的互斥量，那偏向鎖就是在無競爭的情況下把整個同步都消除掉，連CAS操作都不做了。
偏向鎖的“偏”，就是偏心的“偏”、偏袒的“偏”。它的意思是這個鎖會偏向於第一個獲得它的執行緒，如果在接下來的執行過程中，該鎖沒有被其他的執行緒獲取，則持有偏向鎖的執行緒將永遠不需要再進行同步。
      如果讀者讀懂了前面輕量級鎖中關於物件頭Mark Word與執行緒之間的操作過程，那偏向鎖的原理理解起來就會很簡單。假設當前虛擬機器啟用了偏向鎖（啟用引數-XX:+UseBiasedLocking，這是JDK 1.6的預設值），那麼，當鎖物件第一次被執行緒獲取的時候，虛擬機器將會把物件頭中的標誌位設為“01”，即偏向模式。同時使用CAS操作把獲取到這個鎖的執行緒的ID記錄在物件的Mark Word之中，如果CAS操作成功，持有偏向鎖的執行緒以後每次進入這個鎖相關的同步塊時，虛擬機器都可以不再進行任何同步操作（例如Locking、Unlocking及對Mark Word的Update等）。
      當有另外一個執行緒去嘗試獲取這個鎖時，偏向模式就宣告結束。根據鎖物件目前是否處於被鎖定的狀態，撤銷偏向（Revoke Bias）後恢復到未鎖定（標誌位為“01”）或輕量級鎖定（標誌位為“00”）的狀態，後續的同步操作就如上面介紹的輕量級鎖那樣執行。偏向鎖、輕量級鎖的狀態轉化及物件Mark Word的關係如圖13-5所示。

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

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

原創文章，轉載請註明以下資訊：
作者：[email protected]