基於synchronized鎖的深度解析
- 2020 年 11 月 9 日
- 筆記
1. 問題引入
小夥伴們都接觸過執行緒，也都會使用執行緒，今天我們要講的是執行緒安全相關的內容，在這之前我們先來看一個簡單的程式碼案例。
程式碼案例：
/**
* @url: i-code.online
* @author: AnonyStar
* @time: 2020/10/14 15:39
*/
public class ThreadSafaty {
//共享變數
static int count = 0;
public static void main(String[] args) {
//創建執行緒
Runnable runnable = () -> {
for (int i = 0; i < 5; i++) {
count ++;
try {
Thread.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
};
for (int i = 0; i < 100; i++) {
new Thread(runnable,"Thread-"+i).start();
}
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("count = "+ count);
}
}
執行結果：
問題說明：
在上面的程式碼中我們可以看到，定義了一個執行緒 runnable 裡面對公共成員變數進行 ++ 操作，並循環五次，每次睡眠一毫秒，之後我們在主執行緒 main 方法中創建一百個執行緒並且啟動，然後主執行緒睡眠等待五秒以此來等所有的執行緒執行結束。我們預期結果應該是 500 。但是實際執行後我們發現 count 的值是不固定的 ，是小於 500 的，這裡就是多執行緒並行導致的數據安全性問題！
通過上述案例我們可以清楚的看到執行緒安全的問題，那麼我們想想是否有什麼辦法來避免這種安全問題尼 ？我們可以想到導致這種安全問題的原因是因為我們訪問了共享數據，那麼我們是否能將執行緒訪問共享數據的過程變成串列的過程那麼不就是不存在這個問題了。這裡我們可以想到之前說的
鎖，我們知道鎖是處理並發的一種同步方式，同時他也具備互斥性，在Java中實現加鎖是通過synchronized關鍵字
2. 鎖的基本認識
2.1 Synchronized 的認識
在Java 中我們知道有一個元老級的關鍵字 synchronized ，它是實現加鎖的關鍵，但是我們一直都認為它是一個重量級鎖，其實早在 jdk1.6 時就對其進行了大量的優化，讓它已經變成非常靈活。也不再一直是重量級鎖了，而是引入了 **偏向鎖 **和 **輕量級鎖。 **關於這些內容我們將詳細介紹。
synchronized的基礎使用
synchronized修飾實例方法，作用於當前實例加鎖synchronized修飾靜態方法，作用於當前類對象加鎖，synchronized修飾程式碼塊，指定加鎖對象，對給定對象加鎖，
在上述情況中，我們要進入被
synchronized修飾的同步程式碼前，必須獲得相應的鎖，其實這也體現出來針對不同的修飾類型，代表的是鎖的控制粒度
- 我們修改一下前面我們寫的案例，通過使用
synchronized關鍵字讓其實現執行緒安全
//創建執行緒
Runnable runnable = () -> {
synchronized (ThreadSafaty.class){
for (int i = 0; i < 5; i++) {
count ++;
try {
Thread.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
};
只需要添加
synchronized (ThreadSafaty.class)的修飾，將操作的內容放入程式碼塊中，那麼就會實現執行緒安全
Java中鎖的實現
- 我們知道鎖是具有互斥性(
Mutual Exclusion)的 ，那麼它是在什麼地方標記存在的尼？ - 我們也知道多個執行緒都可以獲取鎖，那麼鎖必然是可以共享的
- 我們最熟悉的
synchronized它獲取鎖的過程到底是怎麼樣的呢？它的鎖是如何存儲的呢？ - 我們可以注意觀察
synchronized的語法，可以看到synchronized(lock)是基於lock的生命周期來實現控制鎖粒度的，這裡一定要理解，我們獲得鎖時都時一個對象，那麼鎖是不是會和這個對象有關係呢？ - 到這裡為止，我們將所有的關鍵資訊都指向了對象，那麼我們有必要以此為切入點，來首先了解對象在
jvm中的分布形式，再來看鎖是怎麼被實現的。
對象的記憶體布局
- 這裡我們只談論對象在
Heap中的布局，而不會涉及過多的關於對象的創建過程等細節，這些內容我們再單獨文章詳細闡述，可以關注i-code.online部落格或wx"雲棲簡碼" - 在我們最常用的虛擬機
hotspot中對象在記憶體中的分布可以分為三個部分：對象頭（Header）、實列數據（Instance Data）、對其填充（Padding）
- 通過上述的圖示我們可以看到，對象在記憶體中，包含三個部分， 其中對象頭內分為 對象標記與類元資訊，在對象標記中主要包含如圖所示
hashcode、GC分代年齡、鎖標記狀態、偏向鎖持有執行緒id、執行緒持有的鎖(monitor)等六個內容，這部分數據的長度在 32 位和64位的虛擬機中分別為32bit 和 64bit，在官方將這部分稱為Mark Word。 Mark Word實際是一中可以動態定義的數據結構，這樣可以讓極小的空間存儲盡量多的數據，根據對象的狀態復用自己的記憶體空間，比如在32位的虛擬機中，如果對象未被同步鎖鎖定的狀態下，Mark Word的32個比特存儲單元中，25個用於存儲哈希碼，4個用於存儲GC分代年齡，2個存鎖標記位，1個固定位0，針對各個狀態下的分布可以直觀的參看下面的圖表
32位HotSpot虛擬機對象頭Mark Word
| 鎖狀態 | 25bit | 4bit | 1bit (是否是偏向鎖) |
2bit (鎖標誌位) |
|
|---|---|---|---|---|---|
| 23bit | 2bit | ||||
| 無鎖 | 對象的HashCode | 分代年齡 | 0 | 01 | |
| 偏向鎖 | 執行緒ID | Epoch(偏向時間戳) | 分代年齡 | 1 | 01 |
| 輕量級鎖 | 指向棧中鎖記錄的指針 | 00 | |||
| 重量級鎖 | 指向重量級鎖的指針 | 10 | |||
| GC標記 | 空 | 11 |
上述說的是32位虛擬機，需要注意。關於對象頭的另一部分是類型指針，這裡我們不展開再細說了，想了解的關注
i-code.online,會持續更新相關內容😁😊
- 下面內容會涉及到源碼的查看，需要提前下載源碼，如果你不知道如何來下載，可以參看《下載JDK 與 Hotspot 虛擬機源碼》這篇文章，或者關注
雲棲簡碼。 - 在我們熟悉的虛擬機
Hotspot中實現Mark Word的程式碼在markOop.cpp中，我們可以看下面片段，這是描述了虛擬機中MarkWord的存儲布局：
- 當我們在
new一個對象時，虛擬機層面實際會創建一個instanceOopDesc對象，我們熟悉的Hotspot虛擬機採用了OOP-Klass模型來描述Java對象實例，其中OOP就是我們熟悉的普通對象指針，而Klass則是描述對象的具體類型，在Hotspot中分別用instanceOopDesc和arrayOopDesc來描述，其中arrayOopDesc用來描述數組類型， - 對於
instanceOopDesc的實現我們可以從Hotspot源碼中找到。對應在instanceOop.hpp文件中，而相應的arrayOopDesc在arrayOop.hpp中，下面我們來看一下相關的內容：
- 我們可以看到
instanceOopDesc繼承了oopDesc，而oopDesc則定義在oop.hpp中，
- 上述圖示中我們可以看到相關資訊，具體也注釋了文字，那麼接下來我們要探索一下
_mark的實現定義了，如下，我們看到它是markOopDesc
- 通過程式碼跟進我們可以在找到
markOopDesc的定義在markOop.hpp文件中，如下圖所示：
- 在上述圖片中我們可以看到，內部有一個枚舉。記錄了
markOop中存儲項，所以在我們實際開發時，當synchronized將某個對象作為鎖時那麼之後的一系列鎖的資訊都和markOop相關。如上面表格中mark word的分布記錄所示具體的各個部分的含義 - 因為我們創建對象時實際在jvm層面都會生成一個
native的c++對象oop/oopdesc來映射的，而每個對象都帶有一個monitor的監視器對象，可以在markOop.hpp中看到，其實在多執行緒中搶奪鎖就是在爭奪monitor來修改相應的標記
Synchronized 的深入
- 在
Java中synchronized是實現互斥同步最基本的方法，它是一個塊結構(Block Structured)的同步語法，在經過javac編譯後會在塊的前後分別形成monitorrenter和monitorexit兩個位元組碼指令，而它們又都需要一個reference類型的參數來指明鎖對象，具體鎖對象取決於synchronized修飾的內容，上面已經說過不在闡述。
《深入理解Java虛擬機》中有這樣的描述：
根據《Java虛擬機規範》的要求，在執行monitorenter指令時，首先要去嘗試獲取對象的鎖。如果 這個對象沒被鎖定，或者當前執行緒已經持有了那個對象的鎖，就把鎖的計數器的值增加一，而在執行 monitorexit指令時會將鎖計數器的值減一。一旦計數器的值為零，鎖隨即就被釋放了。如果獲取對象 鎖失敗，那當前執行緒就應當被阻塞等待，直到請求鎖定的對象被持有它的執行緒釋放為止
- 所以被
synchronized修飾的程式碼塊對同一個執行緒是可重入的，這也就避免了同執行緒反覆進入導致死鎖的可能 - 在
synchronized修飾的程式碼塊直接結束釋放鎖之前，會阻塞後面的其他執行緒
為什麼說synchronized是重量級鎖
- 從執行成本來說，持有鎖是一個重量級(
Heavy-Weight)的操作過程，因為在Java中執行緒都是映射到作業系統的原生內核執行緒上的，如果要阻塞和喚醒某一個執行緒都需要經過作業系統來調度，而這就不可避免的會進行用戶態和內核態的轉換，但是這種轉換是非常耗費處理器時間的，尤其對於本身業務程式碼簡單的程式，可能在這裡耗費的時間比業務程式碼自身執行的時間還長，所以說synchronized是一個重量級的操作，不過在jdk6後對其做了大量的優化，讓它不再顯得那麼重
鎖的優化
- 在
JDK5升級到JDK6後進行一系列關於鎖的改進，通過多種技術手段來優化鎖，讓synchronized不再像以前一樣顯的很重，這其中涉及到適應性自旋（Adaptive Spinning）、鎖消除(Lock Elimination)、鎖膨脹(Lock Coarsening)、輕量級鎖(LightWeight Locking)、偏向鎖(Biased Locking)等，這些都是用來優化和提高多執行緒訪問共享數據的競爭問題。
鎖消除
- 鎖消除是虛擬機在即時編譯器運行時對一些程式碼要求同步，但是被檢測到不可能存在共享數據競爭的鎖進行消除，其中主要的判定依據是基於逃逸分析技術來實現的，關於這塊內容不在這裡展開，後續相關文章介紹。這裡我們簡單理解就是，如果一段程式碼中，在堆上的數據都不會逃逸出去被其他執行緒訪問到，那麼就可以把它們當作棧上的數據來對來，認為它們都是執行緒私有的，從而也就不需要同步加鎖了，
- 關於程式碼中變數是否逃逸，對虛擬機來說需要通過複雜分析才能得到，但是對我們開發人員來說還是相對直觀的，那可能有人會疑惑既然開發人員能清楚還為什麼要多餘的加鎖同步呢？，其實實際上，程式上非常多的同步措施並不是我們開發人員自己加入的，而是
java內部就有大量的存在，比如下面這個典型的例子，下面展示的是字元串的相加
private String concatString(String s1,String s2,String s3){
return s1 + s2 + s3;
}
- 我們知道
String類是被final修飾的不可變類，所以對於字元串的相加都是通過生成新的String對象來試試先的，因此編譯器會對這種操作做優化處理，在JDK5之前會轉換為StringBuffer對象的append()操作，而在JDK5及其之後則轉換為StringBuilder對象來操作。所以上述程式碼在jdk5可能會變成如下：
private 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的作用域被限制在方法內部，而不可能逃逸出方法外讓其他執行緒訪問到，所以這是在經過服務端編譯器的即時編譯後，這段程式碼的所有同步措施都會失效而直接執行。
上述程式碼是為了方便演示而選擇了String，實際來說在jdk5之後都是轉換為Stringbuilder ,也就不存在這個問題了，但是在jdk中類似這種還是非常多的。
鎖粗化
- 關於鎖的粗話其實也是很簡單的理解，我們在開發時總是推薦同步程式碼塊要作用範圍盡量小，盡量只在共享數據的實際作用域中才進行同步，這樣的目的是為了儘可能減少同步的操作，讓其他執行緒能更快的拿到鎖
- 這是多大多數情況，但是總有一些特殊情況，比如在某個系列連續操作的都是對同一個對象反覆的加鎖和解鎖，那麼這會導致不必要的性能損耗
- 也如同上面
String的案例，在連續的append操作都是零碎的同步塊，而且都是同一個鎖對象，這時候會將鎖的範圍擴展，到整個操作序列外部，也就是第一個append之前到最後一個append操作之後，將這些全部放入一個同步鎖中就可以了，這樣就避免了多次的鎖獲取和釋放。
自旋鎖
– 通過之前的了解，我們知道掛起執行緒和恢復執行緒都是會涉及到用戶態和內核態的轉換，而這些都是非常耗時的，這會直接影響虛擬機的並發性能。
– 在我們平時開發中，如果共享數據的鎖定狀態只會持續很短的時間，那麼為了這很短的時間而去掛起阻塞執行緒是非常浪費資源的。尤其現在的電腦都基本是多核處理器，所以在這種前提下，我們是是否可以讓另一個請求鎖對象的執行緒不去掛起，而是稍微等一下，這個等待並不會放棄`CPU` 的執行時間。等待觀察持有鎖的執行緒是否能很快的釋放鎖，其實這個等待就好比是一個空的循環，這種技術就是一個所謂的自旋鎖
– 自旋鎖在`JDK6` 中及已經是默認開啟的了，在`jdk4`時就引入了。自旋鎖並不是阻塞也代替不了阻塞。
– 自旋鎖對處理器數量有一定的要求，同時它是會佔用`CPU` 時間的，雖然它避免了執行緒切換的開銷，但是這之間時存在平衡關係的，假如鎖被佔用的時間很短那麼自旋就非常有價值，會節省大量的時間開銷，但是相反，如果鎖佔用的時間很長，那麼自旋的執行緒就會白白消耗處理器資源，造成性能的浪費。
– 所以自旋鎖必須有一個限度，也就是它自旋的次數，規定一個自旋次數，如果超過這個次數則不再自旋轉而用傳統方式掛起執行緒，
– 自旋的次數默認時十次。但是我們也可以通過 `-XX: PreBlockSpin` 參數來自定義設置
### 自適應自旋鎖
– 在前面我們知道可以自定義自旋次數，但是這個很難有個合理的值，畢竟在程式中怎麼樣的情況都有，我們不可能通過全局設置一個。所以在`JDK6` 之後引入了自適應自旋鎖，也就是對原有的自旋鎖進行了優化
– 自適應自旋的時間不再是固定的，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態決定的，如果在同一個鎖對象上，自旋等待剛剛成功獲得過鎖，並且支援有鎖的執行緒正在運行中，那麼虛擬機就會任務這次自旋也極有再次獲得鎖，那麼就會允許自旋的持續時間更長
– 相應的 ，如果對於某個鎖，自旋獲得鎖的次數非常少，那麼在之後要獲取鎖的時候將直接忽略掉自旋的過程進而直接阻塞執行緒避免浪費處理器資源
# 輕量級鎖
– 輕量級鎖也是 `JDK6` 時加入的新的鎖機制，它的輕量級是相對於通過作業系統互斥量來實現的傳統鎖而言的，輕量級鎖也是一種優化，而不是能替代重量級鎖，輕量級鎖的涉及初衷就是在沒有多執行緒競爭下減少傳統重量級鎖使用作業系統互斥量產生的性能消耗。
– 要想了解輕量級鎖我們必須對對象在`Heap` 中的分布了解，也就是上面說到的內容。
### 輕量級鎖加鎖
– 當程式碼執行到同步程式碼塊時，如果同步對象沒有被鎖定也就是鎖標誌位為`01` 狀態，那麼虛擬機首先將在當前執行緒的棧幀中建立一個名為鎖記錄`Lock Record` 的空間
– 這塊鎖記錄空間用來存儲鎖對象目前的 `Mark Word` 的拷貝，官方給其加了個`Displaced` 的前綴，即 `Displaced Mark Word` ，如下圖所示，這是在`CAS` 操作之前堆棧與對象的狀態
– 當複製結束後虛擬機會通過`CAS` 操作嘗試把對象的`Mark Word` 更新為指向`Lock Record` 的指針，如果更新成功則代表該執行緒擁有了這個對象的鎖，並且將`Mark Word` 的鎖標誌位（最後兩個比特）轉變為 「00」，此時表示對象處於輕量級鎖定狀態，此時的堆棧與對象頭的狀態如下：
– 如果上述操作失敗了，那說明至少存在一條執行緒與當前執行緒競爭獲取該對象的鎖，虛擬機會首先檢查對象的`Mark Word` 是否指向當前執行緒的棧幀，如果是，則說明當前執行緒已經擁有了這個對象的鎖，那麼直接進入同步程式碼塊執行即可。否則則說明這個對象已經被其他執行緒搶佔了。
– 如果有超過兩條以上的執行緒爭奪同一個鎖的情況，那麼輕量級鎖就不再有效，必須膨脹為重量級鎖，鎖的標記位也變為「10」，此時`Mark Word` 中存儲的就是指向重量級鎖的指針，等待的執行緒也必須進入阻塞狀態
### 輕量級鎖的解鎖
– 輕量級鎖的解鎖同樣是通過`CAS` 操作來進行的
– 如果對象的 `Mark Word` 仍然指向執行緒的鎖記錄，那麼就用`CAS` 操作把對象當前的 `Mark Word` 和執行緒中複製的 `Displaced Mark Word` 替換回來
– 如果替換成功則整個同步過程結束，若失敗則說明有其他執行緒正在嘗試獲取該鎖，那就要在釋放鎖的同時，喚醒被掛起的執行緒
> 輕量級鎖適用的場景是對於絕大部分鎖在整個同步周期內都是不存在競爭的，因為如果沒有競爭，輕量級鎖便可以通過`CAS` 操作成功避免了使用互斥量的開銷，但是如果確實存在鎖競爭，那麼除了互斥量本身的開銷外還得額外發生了`CAS` 操作的開銷，這種情況下反而比重量級鎖更慢
偏向鎖
- 偏向鎖也是
JDK6引入的一種鎖優化技術，如果說輕量級鎖是在無競爭情況下通過CAS操作消除了同步使用的互斥量，那麼偏向鎖則是再無競爭情況下把整個同步都給消除掉了，連CAS操作都不再去做了，可以看出這比輕量級鎖更加輕 - 從對象頭的分布上看，偏向鎖中是沒有哈希值的而是多了執行緒ID與
Epoch兩個內容 - 偏向鎖的意思就是鎖會偏向第一個獲得它的執行緒，如果接下來的執行過程中該鎖一直沒有被其他執行緒獲取，那麼只有偏向鎖的執行緒將永遠不需要再進行同步
偏向鎖的獲取和撤銷
- 當程式碼執行到同步程式碼塊時，在第一次被執行緒執行到時，鎖對象是第一次被執行緒獲取，此時虛擬機會將對象頭中的鎖標誌改為「01」，同時把偏向鎖標誌位改為「1」，表示當前鎖對象進入偏向鎖模式。
- 接下來執行緒通過
CAS操作來將這個幀的執行緒ID記錄到對象頭中，如果CAS成功了。則持有鎖對象的執行緒再之後進入同步程式碼不再進行任何同步操作（如獲取鎖解鎖等操作）。每次都會通過判斷當前執行緒與鎖對象中記錄的執行緒id是否一致。 - 如果 上述的
CAS操作失敗了，那說明肯定存在另外一個執行緒在獲取這個鎖，並且獲取成功了。這種情況下說明存在鎖競爭，則偏向模式馬上結束，偏向鎖的撤銷，需要等待全局安全點(在這個時間點上沒有正在執行的位元組碼)。它會首先暫停擁有偏向鎖的執行緒，會根據鎖對象是否處於鎖定狀態來決定是否撤銷偏向也就是將偏向鎖標誌位改為「0」，如果撤銷則會變為未鎖定（「01」）或者輕量級鎖（「00」） - 如果鎖對象未鎖定，則撤銷偏向鎖（設置偏向鎖標誌位為「0」），此時鎖處於未鎖定不可以偏向狀態，因為具有哈希值，進而變為輕量級鎖
- 如果鎖對象還在鎖定狀態則直接進入輕量級鎖狀態
偏向鎖的開關
- 偏向鎖在
JDK6及其之後是默認啟用的。由於偏向鎖適用於無鎖競爭的場景，如果我們應用程式里所有的鎖通常情況下處於競爭狀態，可以通過JVM參數關閉偏向鎖：-XX:-UseBiasedLocking=false，那麼程式默認會進入輕量級鎖狀態。 - 如果要開啟偏向鎖可以用：
-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
重量級鎖
- 重量級鎖也就是上述幾種優化都無效後，膨脹為重量級鎖，通過互斥量來實現，我們先來看下面的程式碼
- 上面程式碼是一個簡單使用了
synchronized的程式碼，我們通過位元組碼工具可以看到右側窗口。我們發現，在同步程式碼塊的前後分別形成了monitorenter和monitorexit兩條指令 - 在Java對現中都會有一個
monitor的監視器，這裡的monitorenter指令就是去獲取一個對象的監視器。而相應的monitorexit則表示釋放監視器monitor的所有權，允許被其他執行緒來獲取 monitor是依賴於系統的MutexLock(互斥鎖) 來實現的，當執行緒阻塞後進入內核態事，就會造成系統在用戶態和內核態之間的切換，進而影響性能
總結
- 上面是闡述了關於
synchronized鎖的一些優化與轉換，在我們開啟偏向鎖和自旋時，鎖的轉變是 無鎖 -> 偏向鎖 -> 輕量級鎖 -> 重量級鎖， - 自旋鎖實際是一種鎖的競爭機制，而不是一種狀態。在偏向鎖和輕量級鎖中都使用到了自旋
- 偏向鎖適用於無鎖競爭的場景，輕量級鎖適合無多個執行緒競爭的場景
- 偏向鎖和輕量級鎖都依賴與
CAS操作，但是偏向鎖中只有在第一次時才會CAS操作 - 當一個對象已經被計算過一致性哈希值時，那麼這個對象就再也不無法進入到偏向鎖狀態了，如果對象正處於偏向鎖狀態，而接收到計算哈希值的請求，那麼他的偏向鎖狀態會被立即撤銷，並且會膨脹為重量級鎖。這要是為什麼偏向鎖狀態時
MarkWord中沒有哈希值
本文由AnonyStar 發布,可轉載但需聲明原文出處。
歡迎關注微信公帳號 ：雲棲簡碼 獲取更多優質文章
更多文章關注筆者部落格 ：雲棲簡碼 i-code.online
