是兄弟！就來看這篇多線程！叄

時間 2020-12-02

原文原文鏈接

開篇閒扯

打工人，打工魂，咱們生而人上人。當「資本主義」逐漸禁錮咱們人（大）上（韭）人（菜）肉體的時候，那一刻我才明白那個日不落帝國·資本主義收割機·瑞民族之光幸·瑞幸咖啡是多麼的了不得，儘管我不懂咖啡，但仍是要說一聲謝謝！說到咖啡，喝完就想上廁所，對寫bug的我來講太不友好了，畢竟我不（很）喜歡帶薪上廁所。java

迴歸本次的不正經Java文章，本次新聞主要內容有...tui~~嘴瓢了。上篇文章末尾處已經提到了，主要會把我對Synchronized的理解進行一次全方位的梳理，若是能幫助到你們吊打面試官，萬分榮幸。面試

Synchronized起源

那是個月黑風高的夜晚，Doug Lee先生像咱們同樣喝了咖啡憋着尿加班到深夜，只是他在寫JDK，咱們在用他的JDK寫BUG。在創做JDK1.5以前，他忘了在Java語言中提供同步可擴展的同步接口或者方法了，因而在1.5以前給了咱們一個惡Synchronized湊合用一下，而到了JDK1.5以後，增長了Lock接口及不少原生的併發包供咱們使用。所以，Synchronized做爲關鍵字的形式存在了好久，且在後續JDK1.6的版本中對它作了不少優化，從而提高它的性能，使它可以跟Lock有一戰之力。好了，講完了，再見！微信

Synchronized是什麼

若是我說，Synchronized是一種基於JVM中對象監視器的隱式非公平可重入重量級鎖（這頭銜跟瑞幸有一拼），加解鎖都是靠JVM內部自動實現的，吧啦吧啦...簡稱"面試八股文"，很顯然我不能這麼寫，這樣還不如直接甩個博客連接來的快。來，解釋一下上面那句話，隱式鎖是基於操做系統的MutexLock實現的，每次加解鎖操做都會帶來用戶態與內核態的切換，致使系統增長不少額外的開銷。能夠自行百度學習一下用戶態與內核態的定義，這裏就不贅述了。同時Synchronized的加解鎖過程開發人員是不可控的，失去了可擴展性。多線程

接下來咱們經過一個例子，看一看Synchronized在編譯後究竟是什麼樣子，上才（代）藝（碼）：併發

/**
 * FileName: SynchronizeDetail
 * Author:   RollerRunning
 * Date:     2020/11/30 10:10 PM
 * Description: 詳解Synchronized
 */
public class SynchronizeDetail {
    public synchronized void testRoller() {
        System.out.println("Roller Running!");
    }
    public void testRunning(){
        synchronized (SynchronizeDetail.class){
            System.out.println("Roller Running!");
        }
    }
}

將上面的源代碼進行編譯再輸出編譯後的代碼：高併發

public com.design.model.singleton.SynchronizeDetail();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 9: 0

  public synchronized void testRoller();
    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: ldc           #3                  // String Roller Running!
         5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
         8: return
      LineNumberTable:
        line 14: 0
        line 15: 8

  public void testRunning();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=3, args_size=1
         0: ldc           #5                  // class com/design/model/singleton/SynchronizeDetail
         2: dup
         3: astore_1
         4: monitorenter
         5: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
         8: ldc           #3                  // String Roller Running!
        10: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        13: aload_1
        14: monitorexit
        15: goto          23
        18: astore_2
        19: aload_1
        20: monitorexit
        21: aload_2
        22: athrow
        23: return
      Exception table:
         from    to  target type
             5    15    18   any
            18    21    18   any
      LineNumberTable:
        line 17: 0
        line 18: 5
        line 19: 13
        line 20: 23
      StackMapTable: number_of_entries = 2
        frame_type = 255 /* full_frame */
          offset_delta = 18
          locals = [ class com/design/model/singleton/SynchronizeDetail, class java/lang/Object ]
          stack = [ class java/lang/Throwable ]
        frame_type = 250 /* chop */
          offset_delta = 4
}

觀察一下編譯後的代碼，在testRoller()方法中有這樣一行描述flags: ACC_PUBLIC, ACC_SYNCHRONIZED，表示着當前方法的訪問權限爲SYNCHRONIZED的狀態，而這個標誌就是編譯後由JVM根據Synchronized加鎖的位置增長的鎖標識，也稱做類鎖，凡是要執行該方法的線程，都須要先獲取Monitor對象，直到鎖被釋放之後才容許其餘線程持有Monitor對象。以HotSport虛擬機爲例Monitor的底層又是基於C++ 實現的ObjectMonitor，我不懂C++，經過查資（百）料（度）查到了這個ObjectMonitor的結構以下：佈局

ObjectMonitor::ObjectMonitor() {  
  _header       = NULL;  
  _count       = 0;  
  _waiters      = 0,  
  _recursions   = 0;       //線程重入次數
  _object       = NULL;  
  _owner        = NULL;    //標識擁有該monitor的線程
  _WaitSet      = NULL;    //由等待線程組成的雙向循環鏈表
  _WaitSetLock  = 0 ;  
  _Responsible  = NULL ;  
  _succ         = NULL ;  
  _cxq          = NULL ;    //多線程競爭鎖進入時的單向鏈表
  FreeNext      = NULL ;  
  _EntryList    = NULL ;    //處於等待鎖block狀態的線程的隊列，也是一個雙向鏈表
  _SpinFreq     = 0 ;  
  _SpinClock    = 0 ;  
  OwnerIsThread = 0 ;  
}

那麼接下來就用一張圖說明一下多線程併發狀況下獲取testRoller()方法鎖的過程性能

上文中提到了MutexLock，而圖中加解鎖獲取Monitor對象就是基於它實現的互斥操做，再次強調，在加解鎖過程當中線程會存在內核態與用戶態的切換，所以犧牲了一部分性能。學習

再來講一下testRunning()方法，很顯然，在編譯後的class中出現了一對monitorenter/monitorexit,其實就是對象監視器的另外一種形態，本質上是同樣的，不過區別是，對象在鎖實例方法或者實例對象時稱做內置鎖。而上面的testRoller()是對類（對象的class）的權限控制，二者互不影響。優化

到這裏就解釋Synchronized的基本概念，接下來要說一說它到底跟對象在對空間的內存佈局有什麼關係。

Synchronized與對象堆空間佈局

仍是以64位操做系統下HotSport版本的JVM爲例，看一張全網都搜的到的圖

圖中展現了MarkWord佔用的64位在不一樣鎖狀態下記錄的信息，主要有對象的HashCode、偏向鎖線程ID、GC年齡以及指向鎖的指針等，記住這裏的GC標誌記錄的位置，未來的JVM文章也會用到它，逃不掉的。在上篇例子中查看內存佈局的基礎上稍微改動一下，代碼以下：

/**
 * FileName: JavaObjectMode
 * Author:   RollerRunning
 * Date:     2020/12/01 20:12 PM
 * Description:查看加鎖對象在內存中的佈局
 */
public class JavaObjectMode {
    public static void main(String[] args) {
        //建立對象
        Student student = new Student();
        synchronized(student){
            // 得到加鎖後的對象佈局內容
            String s = ClassLayout.parseInstance(student).toPrintable();
            // 打印對象佈局
            System.out.println(s);
        }
    }
}

class Student{
    private String name;
    private String address;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getAddress() {
        return address;
    }

    public void setAddress(String address) {
        this.address = address;
    }
}

第一張圖是上篇文章的也就是沒加鎖時對象的內存佈局，第二張圖是加鎖後的內存佈局，觀察一下VALUE的值

其實加鎖後，就是修改了對象頭中MarkWord的值用來記錄當前鎖狀態，因此能夠看到加鎖先後VALUE發生了變化。
從第一張圖的第一行VALUE值能夠看出當前的鎖標記爲001（這裏面涉及到一個大端序和小端序的問題，能夠本身學習一下：https://blog.csdn.net/limingliang_/article/details/80815393 ），對應的表中剛好是無鎖狀態，實際代碼也是無鎖狀態。而圖二能夠看出當前鎖標記爲000（提示：在上圖001一樣的位置），對應表中狀態爲輕量級鎖，那麼代碼中的的Synchronized怎麼成了輕量級鎖了呢？由於在JDK1.6之後對鎖進行了優化，Synchronized會在競爭逐漸激烈的過程當中慢慢升級爲重量級互斥鎖。

可是還有問題，爲啥加鎖了，上來就是輕量級鎖而不是偏向鎖呢，緣由是在初始化鎖標記時JVM中默認延遲4s建立偏向鎖，由-XX:BiaseedLockingStartupDelay=xxx控制。一旦建立偏向鎖，在沒有線程使用當前偏向鎖時，叫作匿名偏向鎖，即上表中偏向線程ID的值爲空，當有一個線程過來加鎖時，就進化成了偏向鎖。

到這裏，是否是已經能看明白每天說的鎖也不過是一堆標誌位實現的，讓我寫幾個if-else就給你寫出來了

Synchronized鎖升級過程

鎖的升級過程爲：偏向鎖-->偏向鎖-->輕量級鎖-->重量級鎖。這個過程是隨着線程競爭的激烈程度而逐漸變化的。

偏向鎖

其中匿名偏向鎖前面已經說過了，偏向鎖的做用就是當同一線程屢次訪問同步代碼時，這一線程只須要獲取MarkWord中是否爲偏向鎖，再判斷偏向的線程ID是否是本身，就是倆if-else搞定，Doug Lee先生不過如此嘛。若是發現偏向的線程ID是本身的線程ID就去執行代碼，不是就要經過CAS來嘗試獲取鎖，一旦CAS獲取失敗，就要執行偏向鎖撤銷的操做。而這個過程在高併發的場景會代碼很大的性能開銷，慎重使用偏向鎖。圖爲偏向鎖的內存佈局

輕量級鎖

輕量級鎖是一種基於CAS操做的，適用於競爭不是很激烈的場景。輕量級鎖又分爲自旋鎖和自適應自旋鎖。自旋鎖：由於輕量鎖是基於CAS理論實現的，所以當資源被佔用，其餘線程搶鎖失敗時，會被掛起進入阻塞狀態，當資源就緒時，再次被喚醒，這樣頻繁的阻塞喚醒申請資源，十分低效，所以產生了自旋鎖。JDK1.6中，JVM能夠設置-XX:+UseSpinning參數來開啓自旋鎖，使用-XX:PreBlockSpin來設置自旋鎖次數。不過到了JDK1.7及之後，取消自旋鎖參數，JVM再也不支持由用戶配置自旋鎖，所以出現了自適應自旋鎖。自適應自旋鎖：JVM會根據前一線程持有自旋鎖的時間以及鎖的擁有者的狀態進行動態決策獲取鎖失敗線程的自旋次數，進而優化由於過多線程自旋致使的大量CAS狀態的線程佔用資源。下圖爲輕量級鎖內存佈局：

隨着線程的增多，競爭更加激烈之後，CAS等待已經不能知足需求，所以輕量級鎖又要向重量級鎖邁進了。在JDK1.6以前升級的關鍵條件是超過了自旋等待的次數。在JDK1.7後，因爲參數不可控，JVM會自行決定升級的時機，其中有幾個比較重要的因素：單個線程持有鎖的時間、線程在用戶態與內核態之間切換的時間、掛起阻塞時間、喚醒時間、從新申請資源時間等

重量級鎖

而當升級爲重量級鎖的時候，就沒啥好說的了，鎖標記位爲10，全部線程都要排隊順序執行10標記的代碼，前面提到的每一種鎖以及鎖升級的過程，其實都伴隨着MarkWord中鎖標記位的變化。相信看到這，你們應該都理解了不一樣時期的鎖對應着對象在堆空間中頭部不一樣的標誌信息。重量級鎖的內存佈局我模擬了半天也沒出效果，有興趣的大佬能夠講一下。

最後附上一張圖，展現一下鎖升級的過程，畫圖不易，還請觀衆老爺們關注啊：