面試題：再談Synchronized實現原理！
前言
線程安全是并發編程中的重要關注點。
造成線程安全問題的主要誘因有兩點，一是存在共享數據(也稱臨界資源)，二是存在多條線程共同操作共享數據。
為了解決這個問題，我們可能需要這樣一個方案，當存在多個線程操作共享數據時，需要保證同一時刻有且只有一個線程在操作共享數據，其他線程必須等到該線程處理完數據后再進行。
在 Java 中，關鍵字 Synchronized可以保證在同一個時刻，只有一個線程可以執行某個方法或者某個代碼塊(主要是對方法或者代碼塊中存在共享數據的操作)。
下面來一起探索Synchronized的基本使用、實現機制。
面試題來自：社招一年半面經分享(含阿里美團頭條京東滴滴)
用法
兩類鎖：
對象鎖：包括方法鎖(默認鎖對象為this當前實例對象)和同步代碼塊鎖(自己指定鎖對象)。
類鎖：指Synchronized修飾靜態的方法或指定鎖為Class對象。
當一個線程試圖訪問同步代碼塊時，它首先必須得到鎖，而退出或拋出異常時必須釋放鎖。
- 給普通方法加鎖時，上鎖的對象是 this;
- 給靜態方法加鎖時，鎖的是 class 對象;
- 給代碼塊加鎖，可以指定一個具體的對象作為鎖。
代碼示例如下：
- public class SynchronizedTest {
- /**
- * 修飾靜態方法, 等同于下面注釋的方法
- */
- public synchronized static void test1() {
- System.out.println("月伴飛魚");
- }
- // public static void test1() {
- // synchronized (SynchronizedTest.class){
- // System.out.println("月伴飛魚");
- // }
- // }
- /**
- * 修飾實例方法, 等同于下面注釋的方法
- */
- public synchronized void test2(){
- System.out.println("月伴飛魚");
- }
- // public void test2(){
- // synchronized (this){
- // System.out.println("月伴飛魚");
- // }
- // }
- /**
- * 修飾代碼塊
- */
- public void test3(){
- synchronized (this){
- System.out.println("月伴飛魚");
- }
- }
- }
多線程訪問同步方法的幾種情況：
兩個線程同時訪問一個對象的同步方法。
- 由于同步方法鎖使用的是this對象鎖，同一個對象的this鎖只有一把，兩個線程同一時間只能有一個線程持有該鎖，所以該方法將會串行運行。
兩個線程訪問的是兩個對象的同步方法。
- 由于兩個對象的this鎖互不影響，Synchronized將不會起作用，所以該方法將會并行運行。
兩個線程訪問的是Synchronized的靜態方法。
- Synchronized修飾的靜態方法獲取的是當前類模板對象的鎖，該鎖只有一把，無論訪問多少個該類對象的方法，都將串行執行。
同時訪問同步方法與非同步方法
- 非同步方法不受影響。
訪問同一個對象的不同的普通同步方法。
- 由于this對象鎖只有一個，不同線程訪問多個普通同步方法將串行運行。
同時訪問靜態Synchronized和非靜態Synchronized方法
- 靜態Synchronized方法的鎖為class對象的鎖，非靜態Synchronized方法鎖為this的鎖，它們不是同一個鎖，所以它們將并行運行。
使用優化
大家在使用synchronized關鍵字的時候，可能經常會這么寫：
- synchronized (this) {
- ...
- }
它的作用域是當前對象，鎖的就是當前對象，誰拿到這個鎖誰就可以運行它所控制的代碼。
當有一個明確的對象作為鎖時，就可以這么寫，但是當沒有一個明確的對象作為鎖，只想讓一段代碼同步時，可以創建一個特殊的變量(對象)來充當鎖：
- public class Demo {
- private final Object lock = new Object();
- public void methonA() {
- synchronized (lock) {
- ...
- }
- }
- }
這樣寫沒問題。但是用new Object()作為鎖對象是否是一個最佳選擇呢?
我在StackOverFlow看到這么一篇文章：object-vs-byte0-as-lock
大意就是用new byte[0]作為鎖對象更好，會減少字節碼操作的次數。
- public class Demo {
- private final byte[] lock = new byte[0];
- }
具體細節大家，可以看看這篇文章，算提供一種思路吧!
實現原理
因為Synchronized鎖的是對象，在講解原理之前先介紹下對象結構相關知識。
HotSpot虛擬機中，對象在內存中存儲的布局可以分為三塊區域：對象頭、實例數據和對齊填充。
對象頭
對象頭包括兩部分信息：運行時數據Mark Word和類型指針
如果對象是數組對象，那么對象頭占用3個字寬(Word)(需要記錄數組長度)，如果對象是非數組對象，那么對象頭占用2個字寬(1word = 2Byte = 16bit)
對象頭的類型指針指向該對象的類元數據，虛擬機通過這個指針可以確定該對象是哪個類的實例
Mark Word
用于存儲對象自身的運行時數據， 如哈希碼(HashCode)、GC分代年齡、鎖狀態標志、線程持有的鎖、偏向線程ID、偏向時間戳等等，它是實現輕量級鎖和偏向鎖的關鍵。
這部分數據的長度在32位和64位的虛擬機(暫不考慮開啟壓縮指針的場景)中分別為32個和64個Bits。
Synchronized鎖對象就存儲在MarkWord中，下面是MarkWord的布局：
32位虛擬機
實例數據
實例數據就是在程序代碼中所定義的各種類型的字段，包括從父類繼承的
對齊填充
由于HotSpot的自動內存管理要求對象的起始地址必須是8字節的整數倍，即對象的大小必須是8字節的整數倍，對象頭的數據正好是8的整數倍，所以當實例數據不夠8字節整數倍時，需要通過對齊填充進行補全
意思是每次分配的內存大小一定是8的倍數，如果對象頭+實例數據的值不是8的倍數，那么會重新計算一個較大值，進行分配
底層實現
下面的代碼，在命令行執行 javac，然后再執行javap -v -p，就可以看到它具體的字節碼。
可以看到，在字節碼的體現上，它只給方法加了一個 flag：ACC_SYNCHRONIZED。
- synchronized void syncMethod() {
- System.out.println("syncMethod");
- }
- synchronized void syncMethod();
- descriptor: ()V
- flags: ACC_SYNCHRONIZED
- Code:
- stack=2, locals=1, args_size=1
- 0: getstatic #4
- 3: ldc #5
- 5: invokevirtual #6
- 8: return
我們再來看下同步代碼塊的字節碼。可以看到，字節碼是通過 monitorenter 和monitorexit 兩個指令進行控制的。
- void syncBlock(){
- synchronized (Test.class){
- }
- }
- void syncBlock();
- descriptor: ()V
- flags:
- Code:
- stack=2, locals=3, args_size=1
- 0: ldc #2
- 2: dup
- 3: astore_1
- 4: monitorenter
- 5: aload_1
- 6: monitorexit // 兩個monitorexit是表示正常退出和異常退出的場景
- 7: goto 15
- 10: astore_2
- 11: aload_1
- 12: monitorexit
- 13: aload_2
- 14: athrow
- 15: return
- Exception table:
- from to target type
- 5 7 10 any
- 10 13 10 any
這兩者雖然顯示效果不同，但他們都是通過 monitor 來實現同步的。
其中在Java虛擬機(HotSpot)中，Monitor是由ObjectMonitor實現的，其主要數據結構如下(位于HotSpot虛擬機源碼ObjectMonitor.hpp文件，C++實現的)：
- ObjectMonitor() {
- _header = NULL;
- _count = 0; // 用來記錄該對象被線程獲取鎖的次數，這也說明了synchronized是可重入的
- _waiters = 0,
- _recursions = 0;
- _object = NULL;
- _owner = NULL; // 指向持有ObjectMonitor對象的線程
- _WaitSet = NULL; // 處于wait狀態的線程，會被加入到_WaitSet，調用了wait方法之后會進入這里
- _WaitSetLock = 0 ;
- _Responsible = NULL ;
- _succ = NULL ;
- _cxq = NULL ;
- FreeNext = NULL ;
- _EntryList = NULL ; // 處于等待鎖block狀態的線程，會被加入到該列表
- _SpinFreq = 0 ;
- _SpinClock = 0 ;
- OwnerIsThread = 0 ;
- }
每個 Java 對象在 JVM 的對等對象的頭中保存鎖狀態，指向 ObjectMonitor。
ObjectMonitor 保存了當前持有鎖的線程引用，EntryList 中保存目前等待獲取鎖的線程，WaitSet 保存 wait 的線程。
還有一個計數器count，每當線程獲得 monitor 鎖，計數器 +1，當線程重入此鎖時，計數器還會 +1。當計數器不為 0 時，其它嘗試獲取 monitor 鎖的線程將會被保存到EntryList中，并被阻塞。
當持有鎖的線程釋放了monitor 鎖后，計數器 -1。當計數器歸位為 0 時，所有 EntryList 中的線程會嘗試去獲取鎖，但只會有一個線程會成功，沒有成功的線程仍舊保存在 EntryList 中。
詳細流程：
- 加鎖時，即遇到Synchronized關鍵字時，線程會先進入monitor的_EntryList隊列阻塞等待。
- 如果monitor的_owner為空，則從隊列中移出并賦值與_owner。
- 如果在程序里調用了wait()方法，則該線程進入_WaitSet隊列。我們都知道wait方法會釋放monitor鎖，即將_owner賦值為null并進入_WaitSet隊列阻塞等待。這時其他在_EntryList中的線程就可以獲取鎖了。
- 當程序里其他線程調用了notify/notifyAll方法時，就會喚醒_WaitSet中的某個線程，這個線程就會再次嘗試獲取monitor鎖。如果成功，則就會成為monitor的owner。
- 當程序里遇到Synchronized關鍵字的作用范圍結束時，就會將monitor的owner設為null，退出。
Java對象如何與Monitor關聯
鎖優化
相比于 JDK 1.5，在 JDK 1.6 中 HotSopt 虛擬機對 Synchronized 內置鎖的性能進行了很多優化，包括自適應的自旋、鎖消除、鎖粗化、偏向鎖、輕量級鎖等。
自適應的自旋鎖
在 JDK 1.6 中引入了自適應的自旋鎖來解決長時間自旋的問題。
比如，如果最近嘗試自旋獲取某一把鎖成功了，那么下一次可能還會繼續使用自旋，并且允許自旋更長的時間;但是如果最近自旋獲取某一把鎖失敗了，那么可能會省略掉自旋的過程，以便減少無用的自旋，提高效率。
鎖消除
經過逃逸分析之后，如果發現某些對象不可能被其他線程訪問到，那么就可以把它們當成棧上數據，棧上數據由于只有本線程可以訪問，自然是線程安全的，也就無需加鎖，所以會把這樣的鎖給自動去除掉。
鎖粗化
按理來說，同步塊的作用范圍應該盡可能小，僅在共享數據的實際作用域中才進行同步，這樣做的目的是為了使需要同步的操作數量盡可能縮小，縮短阻塞時間，如果存在鎖競爭，那么等待鎖的線程也能盡快拿到鎖。
但是加鎖解鎖也需要消耗資源，如果存在一系列的連續加鎖解鎖操作，可能會導致不必要的性能損耗。
鎖粗化就是將多個連續的加鎖、解鎖操作連接在一起，擴展成一個范圍更大的鎖，避免頻繁的加鎖解鎖操作。
偏向鎖/輕量級鎖/重量級鎖
JVM 默認會優先使用偏向鎖，如果有必要的話才逐步升級，這大幅提高了鎖的性能。
鎖升級
鎖的狀態總共有四種，無鎖狀態、偏向鎖、輕量級鎖和重量級鎖
隨著鎖的競爭，鎖可以從偏向鎖升級到輕量級鎖，再升級的重量級鎖，但是鎖的升級是單向的，也就是說只能從低到高升級，不會出現鎖的降級
從JDK 1.6中默認是開啟偏向鎖，可以通過-XX:-UseBiasedLocking來禁用偏向鎖
偏向鎖
在只有一個線程使用了鎖的情況下，偏向鎖能夠保證更高的效率。
具體過程是這樣的：當第一個線程第一次訪問同步塊時，會先檢測對象頭 Mark Word 中的標志位 Tag 是否為 01，以此判斷此時對象鎖是否處于無鎖狀態或者偏向鎖狀態。
線程一旦獲取了這把鎖，就會把自己的線程 ID 寫到 MarkWord 中，在其他線程來獲取這把鎖之前，鎖都處于偏向鎖狀態。
當下一個線程參與到偏向鎖競爭時，會先判斷 MarkWord 中保存的線程 ID 是否與這個線程 ID 相等，如果不相等，會立即撤銷偏向鎖，升級為輕量級鎖。
輕量級鎖
當鎖處于輕量級鎖的狀態時，就不能夠再通過簡單地對比標志位 Tag 的值進行判斷，每次對鎖的獲取，都需要通過自旋。
當然，自旋也是面向不存在鎖競爭的場景，比如一個線程運行完了，另外一個線程去獲取這把鎖;但如果自旋失敗達到一定的次數，鎖就會膨脹為重量級鎖。
重量級鎖
重量級鎖，這種情況下，線程會掛起，進入到操作系統內核態，等待操作系統的調度，然后再映射回用戶態。系統調用是昂貴的，所以重量級鎖的名稱由此而來。
如果系統的共享變量競爭非常激烈，鎖會迅速膨脹到重量級鎖，這些優化就名存實亡。
如果并發非常嚴重，可以通過參數-XX:-UseBiasedLocking 禁用偏向鎖，理論上會有一些性能提升，但實際上并不確定。
常見面試題
Synchronized和Lock的區別：
- Synchronized屬于JVM層面，底層通過 monitorenter 和 monitorexit 兩個指令實現，Lock是API層面的東西，JUC提供的具體類
- Synchronized不需要用戶手動釋放鎖，當Synchronized代碼執行完畢之后會自動讓線程釋放持有的鎖，Lock需要一般使用try-finally模式去手動釋放鎖
- Synchronized是不可中斷的，除非拋出異常或者程序正常退出，Lock可中斷，使用lockInterruptibly，調用interrupt方法可中斷
- Synchronized是非公平鎖，Lock默認是非公平鎖，但是可以通過構造函數傳入boolean類型值更改是否為公平鎖
- 鎖是否能綁定多個條件，Synchronized沒有condition的說法，要么喚醒所有線程，要么隨機喚醒一個線程，Lock可以使用condition實現分組喚醒需要喚醒的線程，實現精準喚醒
- Synchronized 鎖只能同時被一個線程擁有，但是 Lock 鎖沒有這個限制，例如在讀寫鎖中的讀鎖，是可以同時被多個線程持有的，可是 Synchronized做不到
- 性能區別：在 Java 5 以及之前Synchronized的性能比較低，但是到了 Java 6 以后 JDK 對 Synchronized 進行了很多優化，比如自適應自旋、鎖消除、鎖粗化、輕量級鎖、偏向鎖等
本文轉載自微信公眾號「月伴飛魚」，可以通過以下二維碼關注。轉載本文請聯系月伴飛魚公眾號。
