在多線程環境中，Synchronized到底該不該用？
在多線程環境中，鎖的使用是避免不了的，使用鎖時候有多種鎖供我們選擇，比如 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());
- }
- }
- }
依靠 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 會有一定的性能損耗。
本文轉載自微信公眾號「古時的風箏」，可以通過以下二維碼關注。轉載本文請聯系古時的風箏公眾號。
