徹底搞懂synchronized(從偏向鎖到重量級鎖)

轉載:線程安全(中)--徹底搞懂synchronized(從偏向鎖到重量級鎖)

 

接觸過線程安全的同學想必都使用過synchronized這個關鍵字，在java同步代碼快中，synchronized的使用方式無非有兩個:

1. 通過對一個對象進行加鎖來實現同步，如下面代碼。

synchronized(lockObject){
    //代碼
}

　　2.對一個方法進行synchronized聲明，進而對一個方法進行加鎖來實現同步。如下面代碼

public synchornized void test(){
    //代碼
}

但這里需要指出的是，無論是對一個對象進行加鎖還是對一個方法進行加鎖，實際上，都是對對象進行加鎖。

 

也就是說，對於方式2，實際上虛擬機會根據synchronized修飾的是實例方法還是類方法，去取對應的實例對象或者Class對象來進行加鎖。

 

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

 

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

想必大家也都聽說過輕量級鎖，重量級鎖，自旋鎖，自適應自旋鎖，偏向鎖等等，他們都有哪些區別呢？
剛才和大家說，鎖是加在對象上的，那么一個線程是如何知道這個對象被加了鎖呢？又是如何知道它加的是什么類型的鎖呢？

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

鎖對象

剛才我們說，鎖實際上是加在對象上的，那么被加了鎖的對象我們稱之為鎖對象，在java中，任何一個對象都能成為鎖對象。
為了讓大家更好着理解虛擬機是如何知道這個對象就是一個鎖對象的，我們下面簡單介紹一下java中一個對象的結構。
java對象在內存中的存儲結構主要有一下三個部分：

1. 對象頭
2. 實例數據
3. 填充數據
   這里強調一下，對象頭里的數據主要是一些運行時的數據。
   其簡單的結構如下

長度	內容	說明
32/64bit	Mark Word	hashCode,GC分代年齡，鎖信息
32/64bit	Class Metadata Address	指向對象類型數據的指針
32/64bit	Array Length	數組的長度(當對象為數組時)

從該表格中我們可以看到，對象中關於鎖的信息是存在Markword里的。
我們來看一段代碼

LockObject lockObject = new LockObject();//隨便創建一個對象
synchronized(lockObject){
    //代碼
}

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

bit fields	是否偏向鎖	鎖標志位
hash	0	01

　　從圖中可以看出，偏向鎖的標志位是“01”，狀態是“0”，表示該對象還沒有被加上偏向鎖。（“1”是表示被加上偏向鎖）。該對象被創建出來的那一刻，就有了偏向鎖的標志位，這也說明了所有對象都是可偏向的，但所有對象的狀態都為“0”，也同時說明所有被創建的對象的偏向鎖並沒有生效。

偏向鎖

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

所謂臨界區，就是只允許一個線程進去執行操作的區域，即同步代碼塊。CAS是一個原子性操作

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

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

此時偏向鎖的狀態為“1”，說明對象的偏向鎖生效了，同時也可以看到，哪個線程獲得了該對象的鎖。

那么，什么是偏向鎖?

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

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

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

鎖膨脹

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

鎖撤銷

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

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

輕量級鎖

鎖撤銷升級為輕量級鎖之后，那么對象的Markword也會進行相應的的變化。下面先簡單描述下鎖撤銷之后，升級為輕量級鎖的過程：

1. 線程在自己的棧楨中創建鎖記錄 LockRecord。
2. 將鎖對象的對象頭中的MarkWord復制到線程的剛剛創建的鎖記錄中。
3. 將鎖記錄中的Owner指針指向鎖對象。
4. 將鎖對象的對象頭的MarkWord替換為指向鎖記錄的指針。

對應的圖描述如下(圖來自周志明深入java虛擬機)

之后Markwork如下：

bit fields	鎖標志位
指向LockRecord的指針	00

注：鎖標志位”00”表示輕量級鎖
輕量級鎖主要有兩種

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

自旋鎖

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

自旋鎖的一些問題

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

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

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

自適應自旋鎖

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

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

重量級鎖

輕量級鎖膨脹之后，就升級為重量級鎖了。重量級鎖是依賴對象內部的monitor鎖來實現的，而monitor又依賴操作系統的MutexLock(互斥鎖)來實現的，所以重量級鎖也被成為互斥鎖。
當輕量級所經過鎖撤銷等步驟升級為重量級鎖之后，它的Markword部分數據大體如下

bit fields	鎖標志位
指向Mutex的指針	10

為什么說重量級鎖開銷大呢

主要是，當系統檢查到鎖是重量級鎖之后，會把等待想要獲得鎖的線程進行阻塞，被阻塞的線程不會消耗cup。但是阻塞或者喚醒一個線程時，都需要操作系統來幫忙，這就需要從用戶態轉換到內核態，而轉換狀態是需要消耗很多時間的，有可能比用戶執行代碼的時間還要長。
這就是說為什么重量級線程開銷很大的。

互斥鎖(重量級鎖)也稱為阻塞同步、悲觀鎖

總結

通過上面的分析，我們知道了為什么synchronized關鍵字為何又深得人心，也知道了鎖的演變過程。
也就是說，synchronized關鍵字並非一開始就該對象加上重量級鎖，也是從偏向鎖，輕量級鎖，再到重量級鎖的過程。
這個過程也告訴我們，假如我們一開始就知道某個同步代碼塊的競爭很激烈、很慢的話，那么我們一開始就應該使用重量級鎖了，從而省掉一些鎖轉換的開銷。

 

參考資料

1. 深入理解java虛擬機(JVM高級特性與最佳實踐)
2. java並發編程
3. Eliminating Synchronization Related Atomic Operations with Biased Locking and Bulk Rebiasing