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