偏向鎖，偏向線程id ,自旋鎖

理解鎖的基礎知識

如果想要透徹的理解Java鎖的來龍去脈，需要先了解以下基礎知識。

基礎知識之一：鎖的類型

鎖從宏觀上分類，分為悲觀鎖與樂觀鎖。

樂觀鎖

樂觀鎖是一種樂觀思想，即認為讀多寫少，遇到並發寫的可能性低，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，采取在寫時先讀出當前版本號，然后加鎖操作（比較跟上一次的版本號，如果一樣則更新），如果失敗則要重復讀-比較-寫的操作。

java中的樂觀鎖基本都是通過CAS操作實現的，CAS是一種更新的原子操作，比較當前值跟傳入值是否一樣，一樣則更新，否則失敗。

悲觀鎖

悲觀鎖是就是悲觀思想，即認為寫多，遇到並發寫的可能性高，每次去拿數據的時候都認為別人會修改，所以每次在讀寫數據的時候都會上鎖，這樣別人想讀寫這個數據就會block直到拿到鎖。java中的悲觀鎖就是Synchronized,AQS框架下的鎖則是先嘗試cas樂觀鎖去獲取鎖，獲取不到，才會轉換為悲觀鎖，如RetreenLock。

基礎知識之二：java線程阻塞的代價

java的線程是映射到操作系統原生線程之上的，如果要阻塞或喚醒一個線程就需要操作系統介入，需要在戶態與核心態之間切換，這種切換會消耗大量的系統資源，因為用戶態與內核態都有各自專用的內存空間，專用的寄存器等，用戶態切換至內核態需要傳遞給許多變量、參數給內核，內核也需要保護好用戶態在切換時的一些寄存器值、變量等，以便內核態調用結束后切換回用戶態繼續工作。

1. 如果線程狀態切換是一個高頻操作時，這將會消耗很多CPU處理時間；
2. 如果對於那些需要同步的簡單的代碼塊，獲取鎖掛起操作消耗的時間比用戶代碼執行的時間還要長，這種同步策略顯然非常糟糕的。

synchronized會導致爭用不到鎖的線程進入阻塞狀態，所以說它是java語言中一個重量級的同步操縱，被稱為重量級鎖，為了緩解上述性能問題，JVM從1.5開始，引入了輕量鎖與偏向鎖，默認啟用了自旋鎖，他們都屬於樂觀鎖。

明確java線程切換的代價，是理解java中各種鎖的優缺點的基礎之一。

基礎知識之三：markword

在介紹java鎖之前，先說下什么是markword，markword是java對象數據結構中的一部分，要詳細了解java對象的結構可以點擊這里,這里只做markword的詳細介紹，因為對象的markword和java各種類型的鎖密切相關；

markword數據的長度在32位和64位的虛擬機（未開啟壓縮指針）中分別為32bit和64bit，它的最后2bit是鎖狀態標志位，用來標記當前對象的狀態，對象的所處的狀態，決定了markword存儲的內容，如下表所示:

狀態	標志位	存儲內容
未鎖定	01	對象哈希碼、對象分代年齡
輕量級鎖定	00	指向鎖記錄的指針
膨脹(重量級鎖定)	10	執行重量級鎖定的指針
GC標記	11	空(不需要記錄信息)
可偏向	01	偏向線程ID、偏向時間戳、對象分代年齡

32位虛擬機在不同狀態下markword結構如下圖所示：

了解了markword結構，有助於后面了解java鎖的加鎖解鎖過程；

小結

前面提到了java的4種鎖，他們分別是重量級鎖、自旋鎖、輕量級鎖和偏向鎖， 
不同的鎖有不同特點，每種鎖只有在其特定的場景下，才會有出色的表現，java中沒有哪種鎖能夠在所有情況下都能有出色的效率，引入這么多鎖的原因就是為了應對不同的情況；

前面講到了重量級鎖是悲觀鎖的一種，自旋鎖、輕量級鎖與偏向鎖屬於樂觀鎖，所以現在你就能夠大致理解了他們的適用范圍，但是具體如何使用這幾種鎖呢，就要看后面的具體分析他們的特性；

 

 

重量級鎖Synchronized

　　

 

 

 　　

它有多個隊列，當多個線程一起訪問某個對象監視器的時候，對象監視器會將這些線程存儲在不同的容器中。

1. Contention List：競爭隊列，所有請求鎖的線程首先被放在這個競爭隊列中；

2. Entry List：Contention List中那些有資格成為候選資源的線程被移動到Entry List中；

3. Wait Set：哪些調用wait方法被阻塞的線程被放置在這里；

4. OnDeck：任意時刻，最多只有一個線程正在競爭鎖資源，該線程被成為OnDeck；

5. Owner：當前已經獲取到所資源的線程被稱為Owner；

6. !Owner：當前釋放鎖的線程。

JVM每次從隊列的尾部取出一個數據用於鎖競爭候選者（OnDeck），但是並發情況下，ContentionList會被大量的並發線程進行CAS訪問，為了降低對尾部元素的競爭，JVM會將一部分線程移動到EntryList中作為候選競爭線程。Owner線程會在unlock時，將ContentionList中的部分線程遷移到EntryList中，並指定EntryList中的某個線程為OnDeck線程（一般是最先進去的那個線程）。Owner線程並不直接把鎖傳遞給OnDeck線程，而是把鎖競爭的權利交給OnDeck，OnDeck需要重新競爭鎖。這樣雖然犧牲了一些公平性，但是能極大的提升系統的吞吐量，在JVM中，也把這種選擇行為稱之為“競爭切換”。

OnDeck線程獲取到鎖資源后會變為Owner線程，而沒有得到鎖資源的仍然停留在EntryList中。如果Owner線程被wait方法阻塞，則轉移到WaitSet隊列中，直到某個時刻通過notify或者notifyAll喚醒，會重新進去EntryList中。

處於ContentionList、EntryList、WaitSet中的線程都處於阻塞狀態，該阻塞是由操作系統來完成的（Linux內核下采用pthread_mutex_lock內核函數實現的）。

Synchronized是非公平鎖。 Synchronized在線程進入ContentionList時，等待的線程會先嘗試自旋獲取鎖，如果獲取不到就進入ContentionList，這明顯對於已經進入隊列的線程是不公平的，還有一個不公平的事情就是自旋獲取鎖的線程還可能直接搶占OnDeck線程的鎖資源。

 

 

 

對於synchronized這個關鍵字，可能之前大家有聽過，他是一個重量級鎖，開銷很大，建議大家少用點。但大家可能也聽說過，但到了jdk1.6之后，該關鍵字被進行了很多的優化，已經不像以前那樣不給力了，建議大家多使用。

那么它是進行了什么樣的優化，才使得synchronized又深得人心呢？為何重量級鎖開銷就大呢？

重量鎖在多線程下會導致線程阻塞；

但是阻塞或者喚醒一個線程時，都需要操作系統來幫忙，這就需要從用戶態轉換到內核態，而轉換狀態是需要消耗很多時間的，有可能比用戶執行代碼的時間還要長。
這就是說為什么重量級線程開銷很大的。

 

 

 

下面我講一步一步講解synchronized是如何被優化的，是如何從偏向鎖到重量級鎖的。

 

 

偏向鎖

  偏向鎖是jdk1.6引入的一項鎖優化，其中的“偏”是偏心的偏。它的意思就是說，這個鎖會偏向於第一個獲得它的線程，在接下來的執行過程中，假如該鎖沒有被其他線程所獲取，沒有其他線程來競爭該鎖，那么持有偏向鎖的線程將永遠不需要進行同步操作。
也就是說:
在此線程之后的執行過程中，如果再次進入或者退出同一段同步塊代碼，並不再需要去進行加鎖或者解鎖操作

當我們創建一個對象LockObject時，該對象的部分Markword關鍵數據如下。

不過，當線程執行到臨界區（critical section）時，此時會利用CAS(Compare and Swap)操作，將線程ID插入到Markword中，同時修改偏向鎖的標志位。

此時的Mark word的結構信息如下：

bit fields		是否偏向鎖	鎖標志位
threadId	epoch	1	01

此時偏向鎖的狀態為“1”，說明對象的偏向鎖生效了，

總結下偏向鎖的步驟：

1. Load-and-test，也就是簡單判斷一下當前線程id是否與Markword當中的線程id是否一致.
2. 如果一致，則說明此線程已經成功獲得了鎖，繼續執行下面的代碼.
3. 如果不一致，則要檢查一下對象是否還是可偏向，即“是否偏向鎖”標志位的值。
4. 如果還未偏向，則利用CAS操作來競爭鎖，也即是第一次獲取鎖時的操作。

如果此對象已經偏向了，並且不是偏向自己，則說明存在了競爭。此時可能就要根據另外線程的情況，可能是重新偏向，也有可能是做偏向撤銷，但大部分情況下就是升級成輕量級鎖了。
可以看出，偏向鎖是針對於一個線程而言的，線程獲得鎖之后就不會再有解鎖等操作了，這樣可以省略很多開銷。假如有兩個線程來競爭該鎖話，那么偏向鎖就失效了，進而升級成輕量級鎖了。
為什么要這樣做呢？因為經驗表明，其實大部分情況下，都會是同一個線程進入同一塊同步代碼塊的。這也是為什么會有偏向鎖出現的原因。
 在Jdk1.6中，偏向鎖的開關是默認開啟的，適用於只有一個線程訪問同步塊的場景。

　　　　

 

 

始終只有一個線程在執行同步塊 在有鎖的競爭時，偏向鎖會多做很多額外操作，尤其是撤銷偏向所的時候會導致進入安全點，安全點會導致stw，導致性能下降，這種情況下應當禁用；

查看停頓–安全點停頓日志

要查看安全點停頓，可以打開安全點日志，通過設置JVM參數 -XX:+PrintGCApplicationStoppedTime 會打出系統停止的時間，添加-XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 這兩個參數會打印出詳細信息，可以查看到使用偏向鎖導致的停頓，時間非常短暫，但是爭用嚴重的情況下，停頓次數也會非常多；

注意：安全點日志不能一直打開： 
1. 安全點日志默認輸出到stdout，一是stdout日志的整潔性，二是stdout所重定向的文件如果不在/dev/shm，可能被鎖。 
2. 對於一些很短的停頓，比如取消偏向鎖，打印的消耗比停頓本身還大。 
3. 安全點日志是在安全點內打印的，本身加大了安全點的停頓時間。

所以安全日志應該只在問題排查時打開。 
如果在生產系統上要打開，再再增加下面四個參數： 
-XX:+UnlockDiagnosticVMOptions -XX: -DisplayVMOutput -XX:+LogVMOutput -XX:LogFile=/dev/shm/vm.log 
打開Diagnostic（只是開放了更多的flag可選，不會主動激活某個flag），關掉輸出VM日志到stdout，輸出到獨立文件,/dev/shm目錄（內存文件系統）。

此日志分三部分： 
第一部分是時間戳，VM Operation的類型 
第二部分是線程概況，被中括號括起來 
total: 安全點里的總線程數 
initially_running: 安全點時開始時正在運行狀態的線程數 
wait_to_block: 在VM Operation開始前需要等待其暫停的線程數

第三部分是到達安全點時的各個階段以及執行操作所花的時間，其中最重要的是vmop

• spin: 等待線程響應safepoint號召的時間；
• block: 暫停所有線程所用的時間；
• sync: 等於 spin+block，這是從開始到進入安全點所耗的時間，可用於判斷進入安全點耗時；
• cleanup: 清理所用時間；
• vmop: 真正執行VM Operation的時間。

可見，那些很多但又很短的安全點，全都是RevokeBias， 高並發的應用會禁用掉偏向鎖。

jvm開啟/關閉偏向鎖

• 開啟偏向鎖：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
• 關閉偏向鎖：-XX:-UseBiasedLocking

 

 

鎖膨脹

剛才說了，當出現有兩個線程來競爭鎖的話，那么偏向鎖就失效了，此時鎖就會膨脹，升級為輕量級鎖。這也是我們經常所說的鎖膨脹

鎖撤銷

由於偏向鎖失效了，那么接下來就得把該鎖撤銷，鎖撤銷的開銷花費還是挺大的，其大概的過程如下：

1. 在一個安全點停止擁有鎖的線程。
2. 遍歷線程棧，如果存在鎖記錄的話，需要修復鎖記錄和Markword，使其變成無鎖狀態。
3. 喚醒當前線程，將當前鎖升級成輕量級鎖。
   所以，如果某些同步代碼塊大多數情況下都是有兩個及以上的線程競爭的話，那么偏向鎖就會是一種累贅，對於這種情況，我們可以一開始就把偏向鎖這個默認功能給關閉

輕量級鎖

 

在代碼進入同步塊的時候，如果此同步對象沒有被鎖定（鎖標志位為“01”狀態），虛擬機首先將在當前線程的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用於存儲鎖對象目前的MarkWord的拷貝（官方把這份拷貝加了一個Displaced前綴，即Displaced Mark Word），這時候線程堆棧與對象頭的狀態如圖13-3所示。

然后，虛擬機將使用CAS操作嘗試將對象的Mark Word更新為指向Lock Record的指針。如果這個更新動作成功了，那么這個線程就擁有了該對象的鎖，並且對象Mark Word的鎖標志位（Mark Word的最后2bit）將轉變為“00”，即表示此對象處於輕量級鎖定狀態，這時候線程堆棧與對象頭的狀態如圖13-4所示。

如果這個更新操作失敗了，虛擬機首先會檢查對象的Mark Word是否指向當前線程的棧幀，如果只說明當前線程已經擁有了這個對象的鎖，那就可以直接進入同步塊繼續執行，否則說明這個鎖對象已經被其他線程搶占了。如果有兩條以上的線程爭用同一個鎖，那輕量級鎖就不再有效，要膨脹為重量級鎖，鎖標志的狀態值變為“10”，Mark Word中存儲的就是指向重量級鎖（互斥量）的指針，后面等待鎖的線程也要進入阻塞狀態。

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

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

 

 

 

 總結偏向鎖撤銷以后升級為輕量級鎖的過程：

1. 線程在自己的棧楨中創建鎖記錄 LockRecord。
2. 將鎖對象的對象頭中的MarkWord復制到線程的剛剛創建的鎖記錄中。
3. 將鎖記錄中的Owner指針指向鎖對象。
4. 將鎖對象的對象頭的MarkWord替換為指向鎖記錄的指針對應的圖描述如下(圖來自周志明深入java虛擬機)
   
   
   

輕量級鎖主要有兩種

1. 自旋鎖
2. 自適應自旋鎖

自旋鎖

所謂自旋，就是指當有另外一個線程來競爭鎖時，這個線程會在原地循環等待，而不是把該線程給阻塞，直到那個獲得鎖的線程釋放鎖之后，這個線程就可以馬上獲得鎖的。
注意，鎖在原地循環的時候，是會消耗cpu的，就相當於在執行一個啥也沒有的for循環。
所以，輕量級鎖適用於那些同步代碼塊執行的很快的場景，這樣，線程原地等待很短很短的時間就能夠獲得鎖了。
經驗表明，大部分同步代碼塊執行的時間都是很短很短的，也正是基於這個原因，才有了輕量級鎖這么個東西。

自旋鎖的一些問題

1. 如果同步代碼塊執行的很慢，需要消耗大量的時間，那么這個時侯，其他線程在原地等待空消耗cpu，這會讓人很難受。
2. 本來一個線程把鎖釋放之后，當前線程是能夠獲得鎖的，但是假如這個時候有好幾個線程都在競爭這個鎖的話，那么有可能當前線程會獲取不到鎖，還得原地等待繼續空循環消耗cup，甚至有可能一直獲取不到鎖。

基於這個問題，我們必須給線程空循環設置一個次數，當線程超過了這個次數，我們就認為，繼續使用自旋鎖就不適合了，此時鎖會再次膨脹，升級為重量級鎖。
默認情況下，自旋的次數為10次，用戶可以通過-XX:PreBlockSpin來進行更改。

自旋鎖是在JDK1.4.2的時候引入的

自適應自旋鎖

所謂自適應自旋鎖就是線程空循環等待的自旋次數並非是固定的，而是會動態着根據實際情況來改變自旋等待的次數。
其大概原理是這樣的：
假如一個線程1剛剛成功獲得一個鎖，當它把鎖釋放了之后，線程2獲得該鎖，並且線程2在運行的過程中，此時線程1又想來獲得該鎖了，但線程2還沒有釋放該鎖，所以線程1只能自旋等待，但是虛擬機認為，由於線程1剛剛獲得過該鎖，那么虛擬機覺得線程1這次自旋也是很有可能能夠再次成功獲得該鎖的，所以會延長線程1自旋的次數。
另外，如果對於某一個鎖，一個線程自旋之后，很少成功獲得該鎖，那么以后這個線程要獲取該鎖時，是有可能直接忽略掉自旋過程，直接升級為重量級鎖的，以免空循環等待浪費資源。

輕量級鎖也被稱為非阻塞同步、樂觀鎖，因為這個過程並沒有把線程阻塞掛起，而是讓線程空循環等待，串行執行。

 

 

 

 

鎖優點的比較