【從刷面試題到構建知識體系】Java底層-synchronized鎖-2偏向鎖篇

上一篇經過構建金字塔結構，來從不一樣的角度，由淺入深的對synchronized關鍵字作了介紹，

快速跳轉：http://www.javashuo.com/article/p-yxisdqpw-ba.html

本文將從底層實現的各個「組件」着手，詳細拆解其工做原理。

本文會分爲如下4節內容：

　　第一節：介紹MarkWord和LockRecord兩種數據結構，該知識點是理解synchronized關鍵字底層原理的關鍵。

　　第二節：分析偏向鎖加鎖解鎖時機和過程

一.先來了解兩種數據結構，你應該瞭解這些知識點

1.MarkWord：在鎖的使用過程當中會對鎖對象做出相應的操做

 在HotSpot虛擬機中，Java對象在內存中存儲的佈局，分爲三個部分：對象頭，實例數據，對齊填充。

本文重點關注對象頭。

對象頭又劃分爲2或3部分，具體包括：

1. MarkWord（後文簡稱MW，後續詳細介紹）
2. 類型指針：指向這個對象所屬的類的元數據(klass)的指針
3. 最後這一部分比較特殊，只有在對象是Java數組時纔會存在，記錄的是數組的長度。爲何要存在這個記錄呢？咱們知道，在普通Java對象中，咱們能夠經過讀取對象所屬類的元數據，計算出對象的大小。而數組是沒法作到的，因而藉助這塊區域來記錄。

本文重點關注MW區域

MW是一塊固定大小內存區域，在32位虛擬機中是32個bit，對應的，64位虛擬機中是64個bit。本文以32位虛擬機爲例分析。

咱們從直觀上理解，所謂的頭信息，通常都是用來記載一些不易變的信息，例如在http請求頭中的各類頭信息。在對象頭中也是如此，例如hashcode。在JVM虛擬機中爲了解決存儲空間開銷，對象頭的MW大小已經固定。那麼，要存儲的信息有比較多，包括且不限於：鎖標誌位、GC信息、鎖相關信息，總大小遠遠超出32bit，怎麼辦呢？

共享存儲區域，在不一樣的時刻，根據需求存儲須要的信息。

請參考下圖：

鎖類型	25bit		4bit	1bit	2bit
	23bit	2bit		是否偏向鎖	鎖標誌位
無鎖	對象hashcode		分代年齡	0	01
偏向鎖	線程ID	epoch	分代年齡	1	01
輕量級鎖	指向棧中鎖記錄的指針				00
重量級鎖	指向互斥量				10
GC標記	空				11

 

說明:兩個標誌位最多隻能標識4個狀態，那麼剩下一個怎麼辦?共享。無鎖和偏向鎖共享01狀態，他們兩個的區分

2.LockRecord：

在當前線程的棧中申請LR（LockRecord簡稱，下同），主要包含兩部分，第一步部分能夠用於存放MW的副本；第二部分obj，用於指向鎖對象。

 上述二者的關係用下圖表示：

 

 

二.偏向鎖怎麼工做

在對象建立的時候，MW會有一個初始態，要麼是無鎖態，要麼是初始偏向鎖態（ThreadId、epoch值都爲初始值0）。程序員的世界不存在二義性，最終總會選一個，選擇的依據是虛擬機的配置參數，在JDK1.6之後，默認是開啓的，若是要禁用掉：-XX:-UseBiasedLocking。

何時須要禁用呢？若是能確認程序在大多數狀況下，都存在多線程競爭，那麼就能夠禁用掉偏向鎖。不必每次都走一遍偏向鎖->輕量級鎖->重量級鎖的完整升級流程。

1.先放一張圖，直觀的描述偏向鎖的加鎖、解鎖、撤銷基本流程

 

 

 

 

2.加鎖過程

 步驟一：

1. LR記錄賦值：在當前線程的棧中，申請一個LR，把obj指向鎖對象

步驟二：如圖中所示，線程T1，執行到同步代碼，嘗試加偏向鎖，首先會作【偏向鎖是否可用】的判斷：

1. 鎖對象的對象頭MW區域後3個bit位的值是101。特別須要注意：若是是001，是無鎖狀態，表明偏向鎖不可用，會走加輕量級鎖流程。
2. ThreadId值：
   1. 若是ThreadId=0，表明無任何線程持有該對象的偏向鎖，能夠執行加鎖操做，進入加鎖流程；
   2. 若是ThreadId!=0，就判斷其值是不是當前線程的ID，分兩種狀況：若是是，直接鎖重入，再也不重複加鎖。若是否，說明是其餘線程（圖中T2）已得到了同步鎖，進入「第三步」鎖競爭流程。
3. epoch值：對象所屬Class裏也會維護一個epoch值，這裏咱們簡稱爲cEpoch，對該值的判斷，可能會致使兩種操做：
   1. 若是epoch<cEpoch，且ThreadId!=0,說明發生過批量重偏向，當前鎖對象已被「釋放」了。此時進行「重偏向」（裏說的釋放並不是真正意義的釋放，而是隱含着一層意思：當前線程已經執行完同步塊，且在某次重偏向操做中，也檢測到這一點，再也不維護epoch的最新值，這樣新的線程認爲此時該偏向鎖，能夠加鎖，直接CAS修改ThreadId便可）。
   2. 若是ThreadId==0，由於偏向鎖沒有顯示的撤銷修改ThreadId過程，說明確定是初始狀態，那麼epoch值也確定是初始狀態0，此時直接進行加鎖操做。

　　　　可加鎖狀態的MW內容以下圖所示：

　　　　

鎖類型	25bit		4bit	1bit	2bit
	23bit	2bit		是否偏向鎖	鎖標誌位
偏向鎖	ThreadId==0	epoch==n	分代年齡	1	01

 

 　　　　以上三個點都判斷經過，進入「第二步」，加鎖流程

第二步：經過CAS原子操做，把T1的ThreadId寫入MW。執行結果有兩種狀況：

1. 寫入成功，得到偏向鎖，進入同步代碼塊執行同步邏輯。
2. 寫入失敗，代表在第一步判斷和CAS操做之間，有其餘線程已得到了鎖。走鎖競爭邏輯。

2.解鎖過程

當前線程執行完同步代碼塊後，進行解鎖，解鎖操做比較簡單，僅僅將棧中的最近一條LR中的obj賦值爲null。這裏須要注意，MW中的threadId並不會作修改。

 

 

3.鎖競爭處理流程

　　持有鎖的線程T2並不會在發現競爭的第一時間就直接撤銷鎖，或者升級鎖，而是執行到安全點後再處理。

1. 此時若是當前線程已執行完同步塊代碼且線程已不存活，將會撤銷鎖，將鎖對象恢復至無鎖狀態，而後進入鎖升級邏輯。
2. 若是當前線程同步塊還未執行完或者線程依然存活，將會走鎖升級流程，升級爲輕量級鎖，且升級完後T2繼續持有輕量級鎖，繼續執行同步代碼。

 

 

 

　　ps：怎麼判斷是否還在執行同步代碼呢？遍歷棧中的RL，若是都爲null，表明鎖已所有釋放。

4.批量重偏向和批量撤銷

有這樣一種場景：若是咱們預判競爭很少，大部分狀況下是單一線程執行同步塊，開啓了偏向鎖。可是在實際使用環境中，出現了大量的競爭，這時候怎麼辦呢？停機從新配置參數？恐怕不是最好的方案。若是是咱們來設計這個這個Synchronized鎖，確定也會作一些兜底策略。好比這樣來作，當某一事件發生了N次，那麼就更改一下處理策略？

是的，基本思想差很少，只不過更完善，暫時留一個懸念，在下次揭曉。