synchronized 到底該不該用？-有解無憂

我是風箏，公眾號「古時的風箏」，一個兼具深度與廣度的程式員鼓勵師，一個本打算寫詩卻寫起了代碼的田園碼農！
文章會收錄在 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 殺手，擅長解決問題，
一個兼具深度與廣度的程式員鼓勵師，本打算寫詩卻寫起了代碼的田園碼農！堅持原創干貨輸出，你可選擇現在就關注我，或者看看歷史文章再關注也不遲，長按二維碼關注，跟我一起變優秀！

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/224920.html

標籤：Java

上一篇：Shiro中@RequiresRoles注解相關引數說明

下一篇：面試題精選:神奇的斐波那契數列