Java的鎖優化

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

互斥同步對性能最大的影響是阻塞的實作，挂起線程和恢複線程的操作都需要轉入核心态中完成，這些操作給系統的并發性能帶來了很大的壓力。同時，虛拟機的開發團隊也注意到在許多應用上，共享資料的鎖定狀态隻會持續很短的一段時間，為了這段時間去挂起和恢複線程并不值得。如果實體機器有一個以上的處理器，能讓兩個或以上的線程同時并行執行，我們就可以讓後面請求鎖的那個線程“稍等一下”，但不放棄處理器的執行時間，看看持有鎖的線程是否很快就會釋放鎖。為了讓線程等待，我們隻需讓線程執行一個忙循環（自旋），這項技術就是所謂的自旋鎖。

自旋鎖在JDK 1.4.2中就已經引入，隻不過預設是關閉的，可以使用-XX：+UseSpinning參數來開啟，在JDK 1.6中就已經改為預設開啟了。自旋等待不能代替阻塞，且先不說對處理器數量的要求，自旋等待本身雖然避免了線程切換的開銷，但它是要占用處理器時間的，是以，如果鎖被占用的時間很短，自旋等待的效果就會非常好，反之，如果鎖被占用的時間很長，那麼自旋的線程隻會白白消耗處理器資源，而不會做任何有用的工作，反而會帶來性能上的浪費。是以，自旋等待的時間必須要有一定的限度，如果自旋超過了限定的次數仍然沒有成功獲得鎖，就應當使用傳統的方式去挂起線程了。自旋次數的預設值是10次，使用者可以使用參數-XX：PreBlockSpin來更改。

在JDK 1.6中引入了自适應的自旋鎖。自适應意味着自旋的時間不再固定了，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀态來決定。如果在同一個鎖對象上，自旋等待剛剛成功獲得過鎖，并且持有鎖的線程正在運作中，那麼虛拟機就會認為這次自旋也很有可能再次成功，進而它将允許自旋等待持續相對更長的時間，比如100個循環。另外，如果對于某個鎖，自旋很少成功獲得過，那在以後要擷取這個鎖時将可能省略掉自旋過程，以避免浪費處理器資源。有了自适應自旋，随着程式運作和性能監控資訊的不斷完善，虛拟機對程式鎖的狀況預測就會越來越準确，虛拟機就會變得越來越“聰明”了。

鎖消除是指虛拟機即時編譯器在運作時，對一些代碼上要求同步，但是被檢測到不可能存在共享資料競争的鎖進行消除。鎖消除的主要判定依據來源于逃逸分析的資料支援，如果判斷在一段代碼中，堆上的所有資料都不會逃逸出去進而被其他線程通路到，那就可以把它們當做棧上資料對待，認為它們是線程私有的，同步加鎖自然就無須進行。

變量是否逃逸，對于虛拟機來說需要使用資料流分析來确定，但是程式員自己應該是很清楚的，怎麼會在明知道不存在資料争用的情況下要求同步呢？答案是有許多同步措施并不是程式員自己加入的，同步的代碼在Java程式中的普遍程度也許超過了想象。由于String是一個不可變的類，對字元串的連接配接操作總是通過生成新的String對象來進行的，是以Javac編譯器會對String連接配接做自動優化。在JDK 1.5之前，會轉化為StringBuffer對象的連續append（）操作，在JDK 1.5及以後的版本中，會轉化為StringBuilder對象的連續append（）操作，客觀地說，既然談到鎖消除與逃逸分析，那虛拟機就不可能是JDK 1.5之前的版本，實際上會轉化為非線程安全的StringBuilder來完成字元串拼接，并不會加鎖。

每個StringBuffer.append（）方法中都有一個同步塊，鎖就是sb對象。虛拟機觀察變量sb，很快就會發現它的動态作用域被限制在concatString（）方法内部。也就是說，sb的所有引用永遠不會“逃逸”到concatString（）方法之外，其他線程無法通路到它，是以，雖然這裡有鎖，但是可以被安全地消除掉，在即時編譯之後，這段代碼就會忽略掉所有的同步而直接執行了。

原則上，我們在編寫代碼的時候，總是推薦将同步塊的作用範圍限制得盡量小——隻在共享資料的實際作用域中才進行同步，這樣是為了使得需要同步的操作數量盡可能變小，如果存在鎖競争，那等待鎖的線程也能盡快拿到鎖。大部分情況下，上面的原則都是正确的，但是如果一系列的連續操作都對同一個對象反複加鎖和解鎖，甚至加鎖操作是出現在循環體中的，那即使沒有線程競争，頻繁地進行互斥同步操作也會導緻不必要的性能損耗。

輕量級鎖是JDK 1.6之中加入的新型鎖機制，它名字中的“輕量級”是相對于使用作業系統互斥量來實作的傳統鎖而言的，是以傳統的鎖機制就稱為“重量級”鎖。首先需要強調一點的是，輕量級鎖并不是用來代替重量級鎖的，它的本意是在沒有多線程競争的前提下，減少傳統的重量級鎖使用作業系統互斥量産生的性能消耗。

要了解輕量級鎖，以及後面會講到的偏向鎖的原理和運作過程，必須從HotSpot虛拟機的對象（對象頭部分）的記憶體布局開始介紹。HotSpot虛拟機的對象頭（Object Header）分為兩部分資訊，第一部分用于存儲對象自身的運作時資料，如哈希碼（HashCode）、GC分代年齡（Generational GC Age）等，這部分資料的長度在32位和64位的虛拟機中分别為32bit和64bit，官方稱它為“Mark Word”，它是實作輕量級鎖和偏向鎖的關鍵。另外一部分用于存儲指向方法區對象類型資料的指針，如果是數組對象的話，還會有一個額外的部分用于存儲數組長度。對象頭資訊是與對象自身定義的資料無關的額外存儲成本，考慮到虛拟機的空間效率，Mark Word被設計成一個非固定的資料結構以便在極小的空間記憶體儲盡量多的資訊，它會根據對象的狀态複用自己的存儲空間。

簡單地介紹了對象的記憶體布局後，我們傳回到輕量級鎖的執行過程上。在代碼進入同步塊的時候，如果此同步對象沒有被鎖定（鎖标志位為“01”狀态），虛拟機首先将在目前線程的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用于存儲鎖對象目前的Mark Word的拷貝（官方把這份拷貝加了一個Displaced字首，即Displaced Mark Word），然後，虛拟機将使用CAS操作嘗試将對象的Mark Word更新為指向Lock Record的指針。如果這個更新動作成功了，那麼這個線程就擁有了該對象的鎖，并且對象Mark Word的鎖标志位（Mark Word的最後2bit）将轉變為“00”，即表示此對象處于輕量級鎖定狀态。如果這個更新操作失敗了，虛拟機首先會檢查對象的Mark Word是否指向目前線程的棧幀，如果是說明目前線程已經擁有了這個對象的鎖，那就可以直接進入同步塊繼續執行，否則說明這個鎖對象已經被其他線程搶占了。如果有兩條以上的線程争用同一個鎖，那輕量級鎖就不再有效，要膨脹為重量級鎖，鎖标志的狀态值變為“10”，Mark Word中存儲的就是指向重量級鎖（互斥量）的指針，後面等待鎖的線程也要進入阻塞狀态。

它的解鎖過程也是通過CAS操作來進行的，如果對象的Mark Word仍然指向着線程的鎖記錄，那就用CAS操作把對象目前的Mark Word和線程中複制的Displaced Mark Word替換回來，如果替換成功，整個同步過程就完成了。如果替換失敗，說明有其他線程嘗試過擷取該鎖，那就要在釋放鎖的同時，喚醒被挂起的線程。

輕量級鎖能提升程式同步性能的依據是“對于絕大部分的鎖，在整個同步周期内都是不存在競争的”，這是一個經驗資料。如果沒有競争，輕量級鎖使用CAS操作避免了使用互斥量的開銷，但如果存在鎖競争，除了互斥量的開銷外，還額外發生了CAS操作，是以在有競争的情況下，輕量級鎖會比傳統的重量級鎖更慢。

偏向鎖也是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”）的狀态，後續的同步操作就如上面介紹的輕量級鎖那樣執行。偏向鎖可以提高帶有同步但無競争的程式性能。它同樣是一個帶有效益權衡（Trade Off）性質的優化，也就是說，它并不一定總是對程式運作有利，如果程式中大多數的鎖總是被多個不同的線程通路，那偏向模式就是多餘的。在具體問題具體分析的前提下，有時候使用參數-XX：-UseBiasedLocking來禁止偏向鎖優化反而可以提升性能。