我是風筝，公衆号「古時的風筝」，一個兼具深度與廣度的程式員鼓勵師，一個本打算寫詩卻寫起了代碼的田園碼農！
文章會收錄在 JavaNewBee 中，更有 Java 後端知識圖譜，從小白到大牛要走的路都在裡面。
在多線程環境中，鎖的使用是避免不了的，使用鎖時候有多種鎖供我們選擇，比如
ReentrantLock
、
CountDownLatch
等等，但是作為 Java 開發者來說，剛剛接觸多線程的時候，最早接觸和使用的恐怕非
synchronized
莫屬了。那你真的了解
synchronized
嗎，今天我們就從以下幾個方面徹底搞懂
synchronized
。
首先有一點要說明一下，各位可能或多或少都聽過這樣的說法：“synchronized 的性能不行，比顯式鎖差很多，開發中還是要慎用。”
大可不必有這樣的顧慮，要說在 JDK 1.6 之前，synchronized 的性能确實有點差，但是 JDK 1.6 之後，JDK 開發團隊已經持續對 synchronized 做了性能優化，其性能已經與其他顯式鎖基本沒有差距了。是以，在考慮是不是使用
synchronized
的時候，隻需要根據場景是否合适來決定，性能問題不用作為衡量标準。
使用方法
synchronized 是一個關鍵字，它的一個明顯特點就是使用簡單，一個關鍵字搞定。它可以在一個方法上使用，也可以在一個方法中的某些代碼塊上使用，非常友善。
public class SyncLock {
private Object lock = new Object();
/**
* 直接在方法上加關鍵字
*/
public synchronized void methodLock() {
System.out.println(Thread.currentThread().getName());
}
/**
* 在代碼塊上加關鍵字，鎖住目前執行個體
*/
public void codeBlockLock() {
synchronized (this) {
System.out.println(Thread.currentThread().getName());
}
}
/**
* 在代碼塊上加關鍵字,鎖住一個變量
*/
public void codeBlockLock() {
synchronized (lock) {
System.out.println(Thread.currentThread().getName());
}
}
}
具體的使用可以參考我之前寫的這篇文章：TODO
依靠 JVM 中的 monitorenter 和 monitorexit 指令控制。通過
javap -v
指令可以看到前面的執行個體代碼中對 synchronized 關鍵字在位元組碼層面的處理，對于在代碼塊上加 synchronized 關鍵字的情況，會通過
monitorenter
和
monitorexit
指令來表示同步的開始和退出辨別。而在方法上加關鍵字的情況，會用
ACC_SYNCHRONIZED
作為方法辨別，這是一種隐式形式，底層原理都是一樣的。
public synchronized void methodLock();
descriptor: ()V
flags: ACC_PUBLIC, ACC_SYNCHRONIZED
Code:
stack=2, locals=1, args_size=1
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: invokestatic #3 // Method java/lang/Thread.currentThread:()Ljava/lang/Thread;
6: invokevirtual #4 // Method java/lang/Thread.getName:()Ljava/lang/String;
9: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
12: return
LineNumberTable:
line 12: 0
line 13: 12
public void codeBlockLock();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=2, locals=3, args_size=1
0: aload_0
1: dup
2: astore_1
3: monitorenter #
4: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
7: invokestatic #3 // Method java/lang/Thread.currentThread:()Ljava/lang/Thread;
10: invokevirtual #4 // Method java/lang/Thread.getName:()Ljava/lang/String;
13: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
16: aload_1
17: monitorexit
18: goto 26
21: astore_2
22: aload_1
23: monitorexit
24: aload_2
25: athrow
26: return
對象布局
為什麼介紹 synchronized 要說到對象頭呢，這和它的鎖更新過程有關系，具體的鎖更新過程稍後會講到，作為鎖更新過程的資料支撐，必須要掌握對象頭的結構才能了解鎖更新的完整過程。
在 Java 中，任何的對象執行個體的記憶體布局都分為對象頭、對象執行個體資料和對齊填充資料三個部分，其中對象頭又包括 MarkWord 和 類型指針。
對象執行個體資料： 這部分就是對象的實際資料。
對齊填充： 因為 HotSpot 虛拟機記憶體管理要求對象的大小必須是8位元組的整數倍，而對象頭正好是8個位元組的整數倍，但是執行個體資料不一定，是以需要對齊填充補全。
對象頭：
Klass 指針： 對象頭中的 Klass 指針是用來指向對象所屬類型的，一個類執行個體究竟屬于哪個類，需要有地方記錄，就在這裡記。
MarkWord: 還有一部分就是和 synchronized 緊密相關的 MarkWord 了，主要用來存儲對象自身的運作時資料，如hashcode、gc 分代年齡等資訊。 MarkWord 的位長度為 JVM 的一個 Word 大小，32位 JVM 的大小為32位，64位JVM的大小為64位。
下圖是 64 位虛拟機下的 MarkWord 結構說明，根據對象鎖狀态不同，某些比特位代表的含義會動态的變化，之是以要這麼設計，是因為不想讓對象頭占用過大的空間，如果為每一個标示都配置設定固定的空間，那對象頭占用的空間将會比較大。
數組長度： 要說明一下，如果是數組對象的話， 由于數組無法通過本身内容求得自身長度，是以需要在對象頭中記錄數組的長度。
源碼中的定義
追根溯源，對象在 JVM 中是怎麼定義的呢？打開 JVM 源碼，找到其中對象的定義檔案，可以看到關于前面說的對象頭的定義。
class oopDesc {
friend class VMStructs;
friend class JVMCIVMStructs;
private:
volatile markOop _mark;
union _metadata {
Klass* _klass;
narrowKlass _compressed_klass;
} _metadata;
}
oop 是對象的基礎類定義，也就是或 Java 中的 Object 類的定義其實就是用的 oop，而任何類都由 Object 繼承而來。oopDesc 隻是 oop 的一個别名而已。
可以看到裡面有關于 Klass 的聲明，還有 markOop 的聲明，這個 markOop 就是對應上面說到的 MarkWord。
class markOopDesc: public oopDesc {
private:
// Conversion
uintptr_t value() const { return (uintptr_t) this; }
public:
// Constants
enum { age_bits = 4, //分代年齡
lock_bits = 2, //鎖标志位
biased_lock_bits = 1, //偏向鎖标記
max_hash_bits = BitsPerWord - age_bits - lock_bits - biased_lock_bits,
hash_bits = max_hash_bits > 31 ? 31 : max_hash_bits,
cms_bits = LP64_ONLY(1) NOT_LP64(0),
epoch_bits = 2
};
}
以上代碼隻是截取了其中一部分，可以看到其中有關于分代年齡、鎖标志位、偏向鎖的定義。
雖然源碼咱也看不太懂，但是當我看到它們的時候，恍惚之間，内心會感歎到，原來如此。有種宇宙之間，已盡在我掌控之中的感覺。過兩天才發現，原來隻是一種心理安慰。但是，已經不重要了。
提示
如果你有興趣翻源碼看看，這部分的定義在
/src/hotspot/share/oops
目錄下，能告訴你的就這麼多了。
鎖更新
JDK 1.6 之後，對 synchronized 做了優化，主要就是 CAS 自旋、鎖消除、鎖膨脹、輕量級鎖、偏向鎖等，這些技術都是為了線上程之間更高效地共享資料及解決競争問題，進而提高程式的執行效率，進而産生了一套鎖更新的規則。
synchronized 的鎖更新過程是通過動态改變對象 MarkWord 各個标志位來表示目前的鎖狀态的，那修改的是哪個對象的 MarkWord 呢，看上面的代碼中，synchronized 關鍵字是加在 lock 變量上的，那就會控制 lock 的 MarkWord。如果是
synchronized(this)
或者在方法上加關鍵字，那控制的就是目前執行個體對象的 MarkWord。
synchronized 的核心準則概括起來大概是這個樣子。
- 能不加鎖就不加鎖。
- 能偏向就盡量偏向。
- 能加輕量級鎖就不用重量級鎖。
無鎖轉向偏向鎖
偏向鎖的意思是說，這個鎖會偏向于第一個獲得它的線程，如果在接下來的執行過程中，該鎖一直沒有被其他的線程擷取，則持有偏向鎖的線程将永遠不需要再進行同步。
當線程嘗試擷取鎖對象的時候，先檢查 MarkWord 中的線程ID 是否為空。如果為空，則虛拟機會将 MarkWord 中的偏向标記設定為 1，鎖标記位為 01。同時，使用 CAS 操作嘗試将線程ID記錄到 MarkWord 中，如果 CAS 操作成功，那之後這個持有偏向鎖的線程再次進入相關同步塊的時候，将不需要再進行任何的同步操作。
如果檢查線程ID不為空，并且不為目前線程ID，或者進行 CAS 操作設定線程ID失敗的情況下，都要撤銷偏向狀态，這時候就要更新為偏向鎖了。
偏向鎖更新到輕量級鎖
當多個線程競争鎖時，偏向鎖會向輕量級鎖狀态更新。
首先，線程嘗試擷取鎖的時候，先檢查鎖标志為是否為 01 狀态，也就是未鎖定狀态。
如果是未鎖定狀态，那就在目前線程的棧幀中建立一個鎖記錄（Lock Record）區域，這個區域存儲 MarkWord 的拷貝。
之後，嘗試用 CAS 操作将 MarkWord 更新為指向鎖記錄的指針（就是上一步線上程棧幀中的 MarkWord 拷貝），如果 CAS 更新成功了，那偏向鎖正式更新為輕量級鎖，鎖标志為變為 00。
如果 CAS 更新失敗了，那檢查 MarkWord 是否已經指向了目前線程的鎖記錄，如果已經指向自己，那表示已經擷取了鎖，否則，輕量級鎖要膨脹為重量級鎖。
輕量級鎖更新到重量級鎖
上面的圖中已經有了關于輕量級鎖膨脹為重量級鎖的邏輯。當鎖已經是輕量級鎖的狀态，再有其他線程來競争鎖，此時輕量級鎖就會膨脹為重量級鎖。
重量級鎖的實作原理
為什麼叫重量級鎖呢？在重量級鎖中沒有競争到鎖的對象會 park 被挂起，退出同步塊時 unpark 喚醒後續線程。喚醒操作涉及到作業系統排程會有額外的開銷，這就是它被稱為重量級鎖的原因。
當鎖更新為重量級鎖的時候，MarkWord 會指向重量級鎖的指針 monitor，monitor 也稱為管程或螢幕鎖， 每個對象都存在着一個 monitor 與之關聯 ，對象與其 monitor 之間的關系有存在多種實作方式，如monitor可以與對象一起建立銷毀或當線程試圖擷取對象鎖時自動生成，但當一個 monitor 被某個線程持有後，它便處于鎖定狀态。
ObjectMonitor中有兩個隊列，_WaitSet 和 _EntryList，用來儲存 ObjectWaiter 對象清單( 每個等待鎖的線程都會被封裝成 ObjectWaiter對象)，_owner 指向持有 ObjectMonitor 對象的線程，當多個線程同時通路一段同步代碼時，首先會進入 _EntryList 集合，當線程擷取到對象的monitor 後進入 _Owner 區域并把 monitor 中的 owner 變量設定為目前線程同時 monitor 中的計數器 count 加1，若線程調用 wait() 方法，将釋放目前持有的 monitor，owner 變量恢複為 null，count 自減1，同時該線程進入 WaitSet 集合中等待被喚醒。若目前線程執行完畢也将釋放 monitor(鎖)并複位變量的值，以便其他線程進入擷取 monitor(鎖)
monitor 對象存在于每個 Java 對象的對象頭中(存儲的指針的指向)，synchronized 鎖便是通過這種方式擷取鎖的，也是為什麼 Java 中任意對象可以作為鎖的原因，同時也是notify/notifyAll/wait等方法存在于頂級對象Object中的原因。
适用場景
偏向鎖
優點： 加鎖和解鎖不需要額外的消耗，和執行非同步方法比僅存在納秒級的差距。
缺點： 如果線程間存在鎖競争，會帶來額外的鎖撤銷的消耗。
适用場景： 适用于隻有一個線程通路同步塊場景。
有的同學可能會有疑惑，适用于隻有一個線程的場景是什麼鬼，一個線程還加什麼鎖。
要知道，有些鎖不是你想不加就不加的。比方說你在使用一個第三方庫，調用它裡面的一個 API，你雖然知道是在單線程下使用，并不需要加鎖，但是第三方庫不知道啊，你調用的這個 API 正好是用 synchronized 做了同步的。這種情況下，使用偏向鎖可以達到最高的性能。
輕量級鎖
優點： 競争的線程不會阻塞，提高了程式的響應速度。
缺點： 如果始終得不到鎖競争的線程使用自旋會消耗CPU。
适用場景： 追求響應時間。同步塊執行速度非常快。
重量級鎖
優點： 線程競争不使用自旋，不會消耗CPU。
缺點： 線程阻塞，響應時間緩慢。
适用場景： 追求吞吐量。同步塊執行速度較長。
總結
1、synchronized 是可重入鎖，是一個非公平的可重入鎖，是以如果場景比較複雜的情況，還是要考慮其他的顯式鎖，比如
Reentrantlock
CountDownLatch
等。
2、synchronized 有鎖更新的過程，當有線程競争的情況下，除了互斥量的本身開銷外，還額外發生了CAS操作的開銷。是以在有競争的情況下，synchronized 會有一定的性能損耗。
這位英俊潇灑的少年，如果覺得還不錯的話，給個推薦可好！
公衆号「古時的風筝」，Java 開發者，全棧工程師，bug 殺手，擅長解決問題。
一個兼具深度與廣度的程式員鼓勵師，本打算寫詩卻寫起了代碼的田園碼農！堅持原創幹貨輸出，你可選擇現在就關注我，或者看看曆史文章再關注也不遲。長按二維碼關注，跟我一起變優秀！
人生沒有回頭路，珍惜當下。