在看java performance的時候看到一些同步的名詞，偏向鎖、輕量級鎖之類的，于是想先了解一下虛擬機中的鎖機制，于是找到了這篇文章。發現是《深入理解Java虛擬機：JVM高級特性與最佳實踐》一書的章節，講得干脆好懂，差點就有要去買一本的沖動-----還是明天吧。以下是文章轉載：
------------------------------------------------------------------------------------------------------------------------------------------------------------------
高效并發是JDK1.6的一個重要主題，HotSpot虛擬機開發團隊在這個版本上花費了大量的精力去實現各種鎖優化技術，如適應性自旋 （AdaptiveSpinning）、鎖削除（Lock Elimination）、鎖膨脹（Lock Coarsening）、輕量級鎖（LightweightLocking）、偏向鎖（BiasedLocking）等，這些技術都是為了在線程之間更高 效地共享數據，以及解決競爭問題，從而提高程序的執行效率。
13.3.1 自旋鎖與自適應自旋 前面我們討論互斥同步的時候，提到了互斥同步對性能最大的影響是阻塞的實現，掛起線程和恢復線程的操作都需要轉入內核態中完成，這些操作給系統的并發 性能帶來了很大的壓力。同時，虛擬機的開發團隊也注意到在許多應用上，共享數據的鎖定狀態只會持續很短的一段時間，為了這段時間去掛起和恢復線程并不值 得。如果物理機器有一個以上的處理器，能讓兩個或以上的線程同時并行執行，我們就可以讓后面請求鎖的那個線程“稍等一會”，但不放棄處理器的執行時間，看 看持有鎖的線程是否很快就會釋放鎖。為了讓線程等待，我們只須讓線程執行一個忙循環（自旋），這項技術就是所謂的自旋鎖。
自旋鎖在JDK 1.4.2中就已經引入，只不過默認是關閉的，可以使用-XX:+UseSpinning參數來開啟，在JDK1.6中就已經改為默認開啟了。自旋等待不 能代替阻塞，且先不說對處理器數量的要求，自旋等待本身雖然避免了線程切換的開銷，但它是要占用處理器時間的，所以如果鎖被占用的時間很短，自旋等待的效 果就會非常好，反之如果鎖被占用的時間很長，那么自旋的線程只會白白消耗處理器資源，而不會做任何有用的工作，反而會帶來性能的浪費。因此自旋等待的時間 必須要有一定的限度，如果自旋超過了限定的次數仍然沒有成功獲得鎖，就應當使用傳統的方式去掛起線程了。自旋次數的默認值是10次，用戶可以使用參數 -XX:PreBlockSpin來更改。
在JDK1.6中引入了自適應的自旋鎖。自適應意味著自旋的時間不再固定了，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。如果在同 一個鎖對象上，自旋等待剛剛成功獲得過鎖，并且持有鎖的線程正在運行中，那么虛擬機就會認為這次自旋也很有可能再次成功，進而它將允許自旋等待持續相對更 長的時間，比如100個循環。另一方面，如果對于某個鎖，自旋很少成功獲得過，那在以后要獲取這個鎖時將可能省略掉自旋過程，以避免浪費處理器資源。有了 自適應自旋，隨著程序運行和性能監控信息的不斷完善，虛擬機對程序鎖的狀況預測就會越來越準確，虛擬機就會變得越來越“聰明”了。
13.3.2 鎖削除 鎖削除是指虛擬機即時編譯器在運行時，對一些代碼上要求同步，但是被檢測到不可能存在共享數據競爭的鎖進行削除。鎖削除的主要判定依據來源于逃逸分析 的數據支持（第11章已經講解過逃逸分析技術），如果判斷到一段代碼中，在堆上的所有數據都不會逃逸出去被其他線程訪問到，那就可以把它們當作棧上數據對 待，認為它們是線程私有的，同步加鎖自然就無須進行。
也許讀者會有疑問，變量是否逃逸，對于虛擬機來說需要使用數據流分析來確定，但是程序員自己應該是很清楚的，怎么會在明知道不存在數據爭用的情況下要 求同步呢？答案是有許多同步措施并不是程序員自己加入的，同步的代碼在Java程序中的普遍程度也許超過了大部分讀者的想象。我們來看看下面代碼清單 13-6中的例子，這段非常簡單的代碼僅僅是輸出三個字符串相加的結果，無論是源碼字面上還是程序語義上都沒有同步。
代碼清單 13-6 一段看起來沒有同步的代碼 Java代碼
- public String concatString(String s1, String s2, String s3) {
- return s1 + s2 + s3;
- }
- public String concatString(String s1, String s2, String s3) {
- return s1 + s2 + s3;
- }
我們也知道，由于String是一個不可變的類，對字符串的連接操作總是通過生成新的String對象來進行的，因此Javac編譯器會對String 連接做自動優化。在JDK 1.5之前，會轉化為StringBuffer對象的連續append()操作，在JDK1.5及以后的版本中，會轉化為StringBuilder對象 的連續append()操作。即代碼清單13-6中的代碼可能會變成代碼清單13-7的樣子 。
代碼清單 13-7 Javac轉化后的字符串連接操作 Java代碼
- 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();
- }
- 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.3.3 鎖膨脹 原則上，我們在編寫代碼的時候，總是推薦將同步塊的作用范圍限制得盡量小——只在共享數據的實際作用域中才進行同步，這樣是為了使得需要同步的操作數量盡可能變小，如果存在鎖競爭，那等待鎖的線程也能盡快地拿到鎖。
大部分情況下，上面的原則都是正確的，但是如果一系列的連續操作都對同一個對象反復加鎖和解鎖，甚至加鎖操作是出現在循環體中的，那即使沒有線程競爭，頻繁地進行互斥同步操作也會導致不必要的性能損耗。
上面代碼清單13-7中連續的append()方法就屬于這類情況。如果虛擬機探測到有這樣一串零碎的操作都對同一個對象加鎖，將會把加鎖同步的范圍 擴展（膨脹）到整個操作序列的外部，以代碼清單13-7為例，就是擴展到第一個append()操作之前直至最后一個append()操作之后，這樣只需 要加鎖一次就可以了。
13.3.4 輕量級鎖 輕量級鎖是JDK1.6之中加入的新型鎖機制，它名字中的“輕量級”是相對于使用操作系統互斥量來實現的傳統鎖而言的，因此傳統的鎖機制就被稱為“重 量級”鎖。首先需要強調一點的是，輕量級鎖并不是用來代替重量級鎖的，它的本意是在沒有多線程競爭的前提下，減少傳統的重量級鎖使用操作系統互斥量產生的 性能消耗。
要理解輕量級鎖，以及后面會講到的偏向鎖的原理和運作過程，必須從HotSpot虛擬機的對象（對象頭部分）的內存布局開始介紹。HotSpot虛擬 機的對象頭（ObjectHeader）分為兩部分信息，第一部分用于存儲對象自身的運行時數據，如哈希碼（HashCode）、GC分代年齡 （Generational GCAge）等，這部分數據的長度在32位和64位的虛擬機中分別為32個和64個Bits，官方稱它為“MarkWord”，它是實現輕量級鎖和偏向鎖 的關鍵。另外一部分用于存儲指向方法區對象類型數據的指針，如果是數組對象的話，還會有一個額外的部分用于存儲數組長度。
對象頭信息是與對象自身定義的數據無關的額外存儲成本，考慮到虛擬機的空間效率，MarkWord被設計成一個非固定的數據結構以便在極小的空間內存 儲盡量多的信息，它會根據對象的狀態復用自己的存儲空間。例如在32位的HotSpot虛擬機中對象未被鎖定的狀態下，MarkWord的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）的空間，用于存儲鎖對象目前的MarkWord的拷貝（官方把這份拷貝加了一個Displaced前綴，即Displaced MarkWord），這時候線程堆棧與對象頭的狀態如圖13-3所示。
圖13-3 輕量級鎖CAS操作之前堆棧與對象的狀態 然后，虛擬機將使用CAS操作嘗試將對象的Mark Word更新為指向LockRecord的指針。如果這個更新動作成功了，那么這個線程就擁有了該對象的鎖，并且對象Mark Word的鎖標志位（MarkWord的最后兩個Bits）將轉變為“00”，即表示此對象處于輕量級鎖定狀態，這時候線程堆棧與對象頭的狀態如圖 13-4所示。
圖13-4 輕量級鎖CAS操作之后堆棧與對象的狀態 （
注2：圖13-3和圖13-4來源于HotSpot虛擬機的一位Senior Staff Engineer——Paul Hohensee所寫的PPT《The Hotspot Java Virtual Machine》）
如果這個更新操作失敗了，虛擬機首先會檢查對象的MarkWord是否指向當前線程的棧幀，如果是就說明當前線程已經擁有了這個對象的鎖，那就可以直 接進入同步塊繼續執行，否則說明這個鎖對象已經被其他線程搶占了。如果有兩條以上的線程爭用同一個鎖，那輕量級鎖就不再有效，要膨脹為重量級鎖，鎖標志的 狀態值變為“10”，MarkWord中存儲的就是指向重量級鎖（互斥量）的指針，后面等待鎖的線程也要進入阻塞狀態。
上面描述的是輕量級鎖的加鎖過程，它的解鎖過程也是通過CAS操作來進行的，如果對象的MarkWord仍然指向著線程的鎖記錄，那就用CAS操作把 對象當前的Mark Word和線程中復制的Displaced MarkWord替換回來，如果替換成功，整個同步過程就完成了。如果替換失敗，說明有其他線程嘗試過獲取該鎖，那就要在釋放鎖的同時，喚醒被掛起的線 程。
輕量級鎖能提升程序同步性能的依據是“對于絕大部分的鎖，在整個同步周期內都是不存在競爭的”，這是一個經驗數據。如果沒有競爭，輕量級鎖使用CAS 操作避免了使用互斥量的開銷，但如果存在鎖競爭，除了互斥量的開銷外，還額外發生了CAS操作，因此在有競爭的情況下，輕量級鎖會比傳統的重量級鎖更慢。
13.3.5 偏向鎖 偏向鎖也是JDK1.6中引入的一項鎖優化，它的目的是消除數據在無競爭情況下的同步原語，進一步提高程序的運行性能。如果說輕量級鎖是在無競爭的情況下使用CAS操作去消除同步使用的互斥量，那偏向鎖就是在無競爭的情況下把整個同步都消除掉，連CAS操作都不做了。
偏向鎖的“偏”，就是偏心的“偏”、偏袒的“偏”。它的意思是這個鎖會偏向于第一個獲得它的線程，如果在接下來的執行過程中，該鎖沒有被其他的線程獲取，則持有偏向鎖的線程將永遠不需要再進行同步。
如果讀者讀懂了前面輕量級鎖中關于對象頭MarkWord與線程之間的操作過程，那偏向鎖的原理理解起來就會很簡單。假設當前虛擬機啟用了偏向鎖（啟 用參數-XX:+UseBiasedLocking，這是JDK1.6的默認值），那么，當鎖對象第一次被線程獲取的時候，虛擬機將會把對象頭中的標志位 設為“01”，即偏向模式。同時使用CAS操作把獲取到這個鎖的線程的ID記錄在對象的MarkWord之中，如果CAS操作成功，持有偏向鎖的線程以后 每次進入這個鎖相關的同步塊時，虛擬機都可以不再進行任何同步操作（例如Locking、Unlocking及對Mark Word的Update等）。
當有另外一個線程去嘗試獲取這個鎖時，偏向模式就宣告結束。根據鎖對象目前是否處于被鎖定的狀態，撤銷偏向（RevokeBias）后恢復到未鎖定 （標志位為“01”）或輕量級鎖定（標志位為“00”）的狀態，后續的同步操作就如上面介紹的輕量級鎖那樣執行。偏向鎖、輕量級鎖的狀態轉化及對象 Mark Word的關系如圖13-5所示。
圖13-5 偏向鎖、輕量級鎖的狀態轉化及對象Mark Word的關系 偏向鎖可以提高帶有同步但無競爭的程序性能。它同樣是一個帶有效益權衡（TradeOff）性質的優化，也就是說它并不一定總是對程序運行有 利，如果程序中大多數的鎖都總是被多個不同的線程訪問，那偏向模式就是多余的。在具體問題具體分析的前提下，有時候使用參數 -XX:-UseBiasedLocking來禁止偏向鎖優化反而可以提升性能。
作者：icyfenix@gmail.com
來源：
《深入理解Java虛擬機：JVM高級特性與最佳實踐》