java併發——synchronized的實現原理

導讀

記得剛剛開始學習Java的時候，一遇到多線程情況就是synchronized，相對於當時的我們來說synchronized是這麼的神奇而又強大，那個時候我們賦予它一個名字“同步”，也成爲了我們解決多線程情況的百試不爽的良藥。但是，隨着我們學習的進行我們知道synchronized是一個重量級鎖，相對於Lock，它會顯得那麼笨重，以至於我們認爲它不是那麼的高效而慢慢摒棄它。
誠然，隨着Javs SE 1.6對synchronized進行的各種優化後，synchronized並不會顯得那麼重了。下面跟隨LZ一起來探索synchronized的實現機制、Java是如何對它進行了優化、鎖優化機制、鎖的存儲結構和升級過程；

實現原理

synchronized可以保證方法或者代碼塊在運行時，同一時刻只有一個方法可以進入到臨界區，同時它還可以保證共享變量的內存可見性

Java中每一個對象都可以作爲鎖，這是synchronized實現同步的基礎：

普通同步方法，鎖是當前實例對象
靜態同步方法，鎖是當前類的class對象
同步方法塊，鎖是括號裏面的對象

那它底層是怎麼實現的呢？我們按照這三種來分析：

同步方法塊

public class SyncTest {
    public void test(){
        synchronized(this){
            System.out.println("-------call test() method---------");
        }
    }
}

通過javap -c SyncTest 查看字節碼

public class SyncTest {
  public SyncTest();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":
()V
       4: return

  public void test();
    Code:
       0: aload_0
       1: dup
       2: astore_1
       3: monitorenter
       4: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
       7: ldc           #3                  // String -------call test() method---------
       9: invokevirtual #4                  // Method java/io/PrintStream.printl
n:(Ljava/lang/String;)V
      12: aload_1
      13: monitorexit
      14: goto          22
      17: astore_2
      18: aload_1
      19: monitorexit
      20: aload_2
      21: athrow
      22: return
    Exception table:
       from    to  target type
           4    14    17   any
          17    20    17   any
}

同步代碼塊： monitorenter指令插入到同步代碼塊的開始位置，monitorexit指令插入到同步代碼塊的結束位置，JVM需要保證每一個monitorenter都有一個monitorexit與之相對應。任何對象都有一個monitor與之相關聯，當且一個monitor被持有之後，他將處於鎖定狀態。線程執行到monitorenter指令時，將會嘗試獲取對象所對應的monitor所有權，即嘗試獲取對象的鎖；

普通同步方法

public class SyncTest {
    public synchronized void test(){
        System.out.println("-------call test() method---------");
    }
}

通過javap -verbose SyncTest 查看字節碼

Classfile /D:/test/SyncTest.class
  Last modified 2017-1-19; size 419 bytes
  MD5 checksum 4c415338276c1a53414a2a3890bbd654
  Compiled from "SyncTest.java"
public class SyncTest
  SourceFile: "SyncTest.java"
  minor version: 0
  major version: 51
  flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
   #1 = Methodref          #6.#14         //  java/lang/Object."<init>":()V
   #2 = Fieldref           #15.#16        //  java/lang/System.out:Ljava/io/PrintStream;
   #3 = String             #17            //  -------call test() method---------
   #4 = Methodref          #18.#19        //  java/io/PrintStream.println:(Ljava/lang/String;)V
   #5 = Class              #20            //  SyncTest
   #6 = Class              #21            //  java/lang/Object
   #7 = Utf8               <init>
   #8 = Utf8               ()V
   #9 = Utf8               Code
  #10 = Utf8               LineNumberTable
  #11 = Utf8               test
  #12 = Utf8               SourceFile
  #13 = Utf8               SyncTest.java
  #14 = NameAndType        #7:#8          //  "<init>":()V
  #15 = Class              #22            //  java/lang/System
  #16 = NameAndType        #23:#24        //  out:Ljava/io/PrintStream;
  #17 = Utf8               -------call test() method---------
  #18 = Class              #25            //  java/io/PrintStream
  #19 = NameAndType        #26:#27        //  println:(Ljava/lang/String;)V
  #20 = Utf8               SyncTest
  #21 = Utf8               java/lang/Object
  #22 = Utf8               java/lang/System
  #23 = Utf8               out
  #24 = Utf8               Ljava/io/PrintStream;
  #25 = Utf8               java/io/PrintStream
  #26 = Utf8               println
  #27 = Utf8               (Ljava/lang/String;)V
{
  public SyncTest();
    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 2: 0

  public synchronized void test();
    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 -------call test() method---------
         5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
         8: return
      LineNumberTable:
        line 5: 0
        line 6: 8
}

普通同步方法：從反編譯的結果來看，當synchronized關鍵詞加在方法上時並沒有通過指令monitorenter和monitorexit來完成（理論上其實也可以通過這兩條指令來實現），不過相對於普通方法，其常量池中多了ACC_SYNCHRONIZED標示符。JVM就是根據該標示符來實現方法的同步的：當方法調用時，調用指令將會檢查方法的 ACC_SYNCHRONIZED 訪問標誌是否被設置，如果設置了，執行線程將先獲取monitor，獲取成功之後才能執行方法體，方法執行完後再釋放monitor。在方法執行期間，其他任何線程都無法再獲得同一個monitor對象。其實本質上沒有區別，只是方法的同步是一種隱式的方式來實現，無需通過字節碼來完成。

靜態同步方法

public class SyncTest {
    public static synchronized void test(){
        System.out.println("-------call test() method---------");
    }
}

通過javap -verbose SyncTest 查看字節碼

Classfile /D:/test/SyncTest.class
  Last modified 2017-1-19; size 419 bytes
  MD5 checksum fe4b3f3196ff30f7113a035ef99f26a0
  Compiled from "SyncTest.java"
public class SyncTest
  SourceFile: "SyncTest.java"
  minor version: 0
  major version: 51
  flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
   #1 = Methodref          #6.#14         //  java/lang/Object."<init>":()V
   #2 = Fieldref           #15.#16        //  java/lang/System.out:Ljava/io/PrintStream;
   #3 = String             #17            //  -------call test() method---------
   #4 = Methodref          #18.#19        //  java/io/PrintStream.println:(Ljava/lang/String;)V
   #5 = Class              #20            //  SyncTest
   #6 = Class              #21            //  java/lang/Object
   #7 = Utf8               <init>
   #8 = Utf8               ()V
   #9 = Utf8               Code
  #10 = Utf8               LineNumberTable
  #11 = Utf8               test
  #12 = Utf8               SourceFile
  #13 = Utf8               SyncTest.java
  #14 = NameAndType        #7:#8          //  "<init>":()V
  #15 = Class              #22            //  java/lang/System
  #16 = NameAndType        #23:#24        //  out:Ljava/io/PrintStream;
  #17 = Utf8               -------call test() method---------
  #18 = Class              #25            //  java/io/PrintStream
  #19 = NameAndType        #26:#27        //  println:(Ljava/lang/String;)V
  #20 = Utf8               SyncTest
  #21 = Utf8               java/lang/Object
  #22 = Utf8               java/lang/System
  #23 = Utf8               out
  #24 = Utf8               Ljava/io/PrintStream;
  #25 = Utf8               java/io/PrintStream
  #26 = Utf8               println
  #27 = Utf8               (Ljava/lang/String;)V
{
  public SyncTest();
    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 2: 0

  public static synchronized void test();
    flags: ACC_PUBLIC, ACC_STATIC, ACC_SYNCHRONIZED
    Code:
      stack=2, locals=0, args_size=0
         0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
         3: ldc           #3                  // String -------call test() method---------
         5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
         8: return
      LineNumberTable:
        line 5: 0
        line 6: 8
}

靜態同步方法：當synchronized關鍵詞加在靜態方法上面，從反編譯的字節碼上來看，多了一個ACC_STATIC標識。

monitorenter和monitorexit

monitorenter
每個對象有一個監視器鎖（monitor）。當monitor被佔用時就會處於鎖定狀態，線程執行monitorenter指令時嘗試獲取monitor的所有權，過程如下：
1、如果monitor的進入數爲0，則該線程進入monitor，然後將進入數設置爲1，該線程即爲monitor的所有者。
2、如果線程已經佔有該monitor，只是重新進入，則進入monitor的進入數加1。
3、如果其他線程已經佔用了monitor，則該線程進入阻塞狀態，直到monitor的進入數爲0，再重新嘗試獲取monitor的所有權。
monitorexit
執行monitorexit的線程必須是objectref所對應的monitor的所有者。指令執行時，monitor的進入數減1，如果減1後進入數爲0，那線程退出monitor，不再是這個monitor的所有者。其他被這個monitor阻塞的線程可以嘗試去獲取這個 monitor 的所有權。通過這兩段描述，我們應該能很清楚的看出Synchronized的實現原理，Synchronized的語義底層是通過一個monitor的對象來完成，其實wait/notify等方法也依賴於monitor對象，這就是爲什麼只有在同步的塊或者方法中才能調用wait/notify等方法，否則會拋出java.lang.IllegalMonitorStateException的異常的原因。

java對象頭

synchronized用的鎖是存在Java對象頭裏的，那麼什麼是Java對象頭呢？Hotspot虛擬機的對象頭主要包括兩部分數據：Mark Word（標記字段）、Klass Pointer（類型指針）。其中Klass Point是是對象指向它的類元數據的指針，虛擬機通過這個指針來確定這個對象是哪個類的實例，Mark Word用於存儲對象自身的運行時數據，它是實現輕量級鎖和偏向鎖的關鍵，所以下面將重點闡述

HotSpot虛擬機的對象頭(Object Header)包括兩部分信息。：
第一部分用於存儲對象自身的運行時數據，如哈希碼（HashCode）、GC分代年齡、鎖狀態標誌、線程持有的鎖、偏向線程ID、偏向時間戳等等，這部分數據的長度在32位和64位的虛擬機（暫不考慮開啓壓縮指針的場景）中分別爲32個和64個Bits，官方稱它爲“Mark Word”。
對象頭的另外一部分是類型指針，即是對象指向它的類的元數據的指針，虛擬機通過這個指針來確定這個對象是哪個類的實例。並不是所有的虛擬機實現都必須在對象數據上保留類型指針，換句話說查找對象的元數據信息並不一定要經過對象本身。另外，如果對象是一個Java數組，那在對象頭中還必須有一塊用於記錄數組長度的數據，因爲虛擬機可以通過普通Java對象的元數據信息確定Java對象的大小，但是從數組的元數據中無法確定數組的大小。
對象頭信息是與對象自身定義的數據無關的額外存儲成本，但是考慮到虛擬機的空間效率，Mark Word被設計成一個非固定的數據結構以便在極小的空間內存存儲儘量多的數據，它會根據對象的狀態複用自己的存儲空間，也就是說，Mark Word會隨着程序的運行發生變化，變化狀態如下（32位虛擬機）：

因此，Synchronized鎖的到底是什麼？——對象。

Monitor

什麼是Monitor？我們可以把它理解爲一個同步工具，也可以描述爲一種同步機制，它通常被描述爲一個對象。
與一切皆對象一樣，所有的Java對象是天生的Monitor，每一個Java對象都有成爲Monitor的潛質，因爲在Java的設計中，每一個Java對象自打孃胎裏出來就帶了一把看不見的鎖，它叫做內部鎖或者Monitor鎖。
Monitor 是線程私有的數據結構，每一個線程都有一個可用monitor record列表，同時還有一個全局的可用列表。每一個被鎖住的對象都會和一個monitor關聯（對象頭的MarkWord中的LockWord指向monitor的起始地址），同時monitor中有一個Owner字段存放擁有該鎖的線程的唯一標識，表示該鎖被這個線程佔用。其結構如下：

owner：初始時爲NULL表示當前沒有任何線程擁有該monitor record，當線程成功擁有該鎖後保存線程唯一標識，當鎖被釋放時又設置爲NULL。
EntryQ:關聯一個系統互斥鎖（semaphore），阻塞所有試圖鎖住monitor record失敗的線程。
RcThis:表示blocked或waiting在該monitor record上的所有線程的個數。
Nest:用來實現重入鎖的計數。
HashCode:保存從對象頭拷貝過來的HashCode值（可能還包含GC age）。
Candidate:用來避免不必要的阻塞或等待線程喚醒，因爲每一次只有一個線程能夠成功擁有鎖，如果每次前一個釋放鎖的線程喚醒所有正在阻塞或等待的線程，會引起不必要的上下文切換（從阻塞到就緒然後因爲競爭鎖失敗又被阻塞）從而導致性能嚴重下降。Candidate只有兩種可能的值0表示沒有需要喚醒的線程1表示要喚醒一個繼任線程來競爭鎖。

鎖優化

jdk1.6對鎖的實現引入了大量的優化，如自旋鎖、適應性自旋鎖、鎖消除、鎖粗化、偏向鎖、輕量級鎖等技術來減少鎖操作的開銷。鎖主要存在四中狀態，依次是：無鎖狀態、偏向鎖狀態、輕量級鎖狀態、重量級鎖狀態，他們會隨着競爭的激烈而逐漸升級。注意鎖可以升級不可降級，這種策略是爲了提高獲得鎖和釋放鎖的效率。

自旋鎖

線程的阻塞和喚醒需要CPU從用戶態轉爲核心態，頻繁的阻塞和喚醒對CPU來說是一件負擔很重的工作，勢必會給系統的併發性能帶來很大的壓力。同時我們發現在許多應用上面，對象鎖的鎖狀態只會持續很短一段時間，爲了這一段很短的時間頻繁地阻塞和喚醒線程是非常不值得的。所以引入自旋鎖。
何謂自旋鎖？
所謂自旋鎖，就是讓該線程等待一段時間，不會被立即掛起，看持有鎖的線程是否會很快釋放鎖。怎麼等待呢？執行一段無意義的循環即可（自旋）。
自旋等待不能替代阻塞，先不說對處理器數量的要求（多核，貌似現在沒有單核的處理器了），雖然它可以避免線程切換帶來的開銷，但是它佔用了處理器的時間。如果持有鎖的線程很快就釋放了鎖，那麼自旋的效率就非常好，反之，自旋的線程就會白白消耗掉處理的資源，它不會做任何有意義的工作，典型的佔着茅坑不拉屎，這樣反而會帶來性能上的浪費。所以說，自旋等待的時間（自旋的次數）必須要有一個限度，如果自旋超過了定義的時間仍然沒有獲取到鎖，則應該被掛起。
自旋鎖在JDK 1.4.2中引入，默認關閉，但是可以使用-XX:+UseSpinning開開啓，在JDK1.6中默認開啓。同時自旋的默認次數爲10次，可以通過參數-XX:PreBlockSpin來調整；如果通過參數-XX:preBlockSpin來調整自旋鎖的自旋次數，會帶來諸多不便。假如我將參數調整爲10，但是系統很多線程都是等你剛剛退出的時候就釋放了鎖（假如你多自旋一兩次就可以獲取鎖），你是不是很尷尬。於是JDK1.6引入自適應的自旋鎖，讓虛擬機會變得越來越聰明。

適應自旋鎖

JDK 1.6引入了更加聰明的自旋鎖，即自適應自旋鎖。所謂自適應就意味着自旋的次數不再是固定的，它是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定。它怎麼做呢？線程如果自旋成功了，那麼下次自旋的次數會更加多，因爲虛擬機認爲既然上次成功了，那麼此次自旋也很有可能會再次成功，那麼它就會允許自旋等待持續的次數更多。反之，如果對於某個鎖，很少有自旋能夠成功的，那麼在以後要或者這個鎖的時候自旋的次數會減少甚至省略掉自旋過程，以免浪費處理器資源。
有了自適應自旋鎖，隨着程序運行和性能監控信息的不斷完善，虛擬機對程序鎖的狀況預測會越來越準確，虛擬機會變得越來越聰明。

鎖消除

爲了保證數據的完整性，我們在進行操作時需要對這部分操作進行同步控制，但是在有些情況下，JVM檢測到不可能存在共享數據競爭，這是JVM會對這些同步鎖進行鎖消除。鎖消除的依據是逃逸分析的數據支持。
如果不存在競爭，爲什麼還需要加鎖呢？所以鎖消除可以節省毫無意義的請求鎖的時間。變量是否逃逸，對於虛擬機來說需要使用數據流分析來確定，但是對於我們程序員來說這還不清楚麼？我們會在明明知道不存在數據競爭的代碼塊前加上同步嗎？但是有時候程序並不是我們所想的那樣？我們雖然沒有顯示使用鎖，但是我們在使用一些JDK的內置API時，如StringBuffer、Vector、HashTable等，這個時候會存在隱形的加鎖操作。比如StringBuffer的append()方法，Vector的add()方法：

    public void vectorTest() {
        Vector<String> vector = new Vector<String>();
        for(int i=0;i<10;i++) {
            vector.add(i+"");
        }
        System.out.println(vector);
    }

在運行這段代碼時，JVM可以明顯檢測到變量vector沒有逃逸出方法vectorTest()之外，所以JVM可以大膽地將vector內部的加鎖操作消除。

鎖粗化

我們知道在使用同步鎖的時候，需要讓同步塊的作用範圍儘可能小—僅在共享數據的實際作用域中才進行同步，這樣做的目的是爲了使需要同步的操作數量儘可能縮小，如果存在鎖競爭，那麼等待鎖的線程也能儘快拿到鎖。
在大多數的情況下，上述觀點是正確的，LZ也一直堅持着這個觀點。但是如果一系列的連續加鎖解鎖操作，可能會導致不必要的性能損耗，所以引入鎖粗話的概念。
鎖粗話概念比較好理解，就是將多個連續的加鎖、解鎖操作連接在一起，擴展成一個範圍更大的鎖。如上面實例：vector每次add的時候都需要加鎖操作，JVM檢測到對同一個對象（vector）連續加鎖、解鎖操作，會合並一個更大範圍的加鎖、解鎖操作，即加鎖解鎖操作會移到for循環之外。

輕量級鎖

引入輕量級鎖的主要目的是在多沒有多線程競爭的前提下，減少傳統的重量級鎖使用操作系統互斥量產生的性能消耗。當關閉偏向鎖功能或者多個線程競爭偏向鎖導致偏向鎖升級爲輕量級鎖，則會嘗試獲取輕量級鎖。
獲取鎖：
1、判斷當前對象是否處於無鎖狀態（hashcode、0、01），若是，則JVM首先將在當前線程的棧幀中建立一個名爲鎖記錄（Lock Record）的空間，用於存儲鎖對象目前的Mark Word的拷貝（官方把這份拷貝加了一個Displaced前綴，即Displaced Mark Word）；否則執行步驟（3）；
2、JVM利用CAS操作嘗試將對象的Mark Word更新爲指向Lock Record的指正，如果成功表示競爭到鎖，則將鎖標誌位變成00（表示此對象處於輕量級鎖狀態），執行同步操作；如果失敗則執行步驟（3）；
3、判斷當前對象的Mark Word是否指向當前線程的棧幀，如果是則表示當前線程已經持有當前對象的鎖，則直接執行同步代碼塊；否則只能說明該鎖對象已經被其他線程搶佔了，這時輕量級鎖需要膨脹爲重量級鎖，鎖標誌位變成10，後面等待的線程將會進入阻塞狀態；
釋放鎖：
1、取出在獲取輕量級鎖保存在Displaced Mark Word中的數據；
2、用CAS操作將取出的數據替換當前對象的Mark Word中，如果成功，則說明釋放鎖成功，否則執行（3）；
3、如果CAS操作替換失敗，說明有其他線程嘗試獲取該鎖，則需要在釋放鎖的同時需要喚醒被掛起的線程。

對於輕量級鎖，其性能提升的依據是“對於絕大部分的鎖，在整個生命週期內都是不會存在競爭的”，如果打破這個依據則除了互斥的開銷外，還有額外的CAS操作，因此在有多線程競爭的情況下，輕量級鎖比重量級鎖更慢；

偏向鎖

引入偏向鎖主要目的是：爲了在無多線程競爭的情況下儘量減少不必要的輕量級鎖執行路徑。上面提到了輕量級鎖的加鎖解鎖操作是需要依賴多次CAS原子指令的。那麼偏向鎖是如何來減少不必要的CAS操作呢？我們可以查看Mark work的結構就明白了。只需要檢查是否爲偏向鎖、鎖標識爲以及ThreadID即可。
獲取鎖：
1、檢測Mark Word是否爲可偏向狀態，即是否爲偏向鎖1，鎖標識位爲01；
2、若爲可偏向狀態，則測試線程ID是否爲當前線程ID，如果是，則執行步驟（5），否則執行步驟（3）；
3、如果線程ID不爲當前線程ID，則通過CAS操作競爭鎖，競爭成功，則將Mark Word的線程ID替換爲當前線程ID，否則執行線程（4）；
4、通過CAS競爭鎖失敗，證明當前存在多線程競爭情況，當到達全局安全點，獲得偏向鎖的線程被掛起，偏向鎖升級爲輕量級鎖，然後被阻塞在安全點的線程繼續往下執行同步代碼塊；
5、執行同步代碼塊
釋放鎖：偏向鎖的釋放採用了一種只有競爭纔會釋放鎖的機制，線程是不會主動去釋放偏向鎖，需要等待其他線程來競爭。偏向鎖的撤銷需要等待全局安全點（這個時間點是上沒有正在執行的代碼）
1、暫停擁有偏向鎖的線程，判斷鎖對象石是否還處於被鎖定狀態；
2、撤銷偏向鎖，恢復到無鎖狀態（01）或者輕量級鎖的狀態；

重量級鎖

重量級鎖通過對象內部的監視器（monitor）實現，其中monitor的本質是依賴於底層操作系統的Mutex Lock實現，操作系統實現線程之間的切換需要從用戶態到內核態的切換，切換成本非常高。

java併發——synchronized的實現原理

導讀

實現原理

monitorenter和monitorexit

java對象頭

Monitor

鎖優化

自旋鎖

適應自旋鎖

鎖消除

鎖粗化

輕量級鎖

偏向鎖

重量級鎖

Wireshark 安裝+使用（一）

Sentinel學習(八) —— 規則持久化

Nacos學習(一) —— Nacos配置管理實戰

Sentinel學習(五) —— 控制檯使用和源碼

Kafka學習(二)——生產者

Kafka學習(一)——初識與入門

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結