如何掌握Synchronized關鍵字

這篇文章主要講解了“如何掌握Synchronized關鍵字”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“如何掌握Synchronized關鍵字”吧！

一、synchronized的用法

1.1、三種使用方式

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 靜態方法

3. 非靜態方法

4. 代碼塊

代碼示例：

public class Test {     //對象     Object object=new Object();     //共享變量     private static int num;     //靜態方法     public synchronized static void lock1(){         num ++;     }     //普通方法     public synchronized  void lock2(){         num ++;     }      public void lock3(){         //代碼塊         synchronized (object){             num ++;         }     } }

1.2、作用范圍

面試時經常會問：synchronized 關鍵字鎖的是什么?或者說它的作用范圍是什么?

總結一下：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 非靜態方法鎖的是當前對象 (就是 this)

3. 靜態方法鎖的是類對象 Test.class

4. 代碼塊鎖的是自定義的 Object 對象

1.3、原子性、可見性、有序性

我們都知道并發編程需要考慮三個問題：原子性、可見性、有序性。

那么，使用 synchronized 關鍵字是如何解決這三個問題的?

• 原子性：synchronized 關鍵字能保證只有一個線程能拿到鎖，能夠進入同步代碼塊，不會出現原子性問題

• 可見性：執行 synchronized 時，對應 lock 原子操作將會清空工作內存中此變量的值，并重新 read  來刷新內存，不會出現可見性的問題

• 有序性：執行 synchronized  時，依然可能發生重排序，只不過，我們有同步代碼塊，可以保證只有一個線程執行同步代碼中的代碼，不會出現有序性問題

二、對象內存布局

上面說了，這三種方式都是鎖的是對象、對象、對象(說三遍)，但是聽起來好像很抽象的樣子，對象還能被鎖?該如何操作?

其實是和對象內存布局有關系。

耳聽為虛，眼見為實，下面讓你親眼看到對象是由啥組成的。

示例代碼：

//1、需要導入包 import org.openjdk.jol.info.ClassLayout; //2、定義Lock類 public class Lock {     int i;     boolean flag; } //3、將Lock對象打印出來 public class Test {     public static void main(String[] args){         Lock lock = new Lock();         System.out.println(ClassLayout.parseInstance(lock).toPrintable());     } }

打印出來的結果是這樣的：

 OFFSET  SIZE      TYPE DESCRIPTION                               VALUE       0     4           (object header)                           01 47 70 9d (00000001 01000111 01110000 10011101) (-1653586175)       4     4           (object header)                           11 00 00 00 (00010001 00000000 00000000 00000000) (17)       8     4           (object header)                           43 c1 00 f8 (01000011 11000001 00000000 11111000) (-134168253)      12     4           int L.i                                   0      16     1           boolean L.flag                            false      17     7           (loss due to the next object alignment) Instance size: 24 bytes Space losses: 0 bytes internal + 7 bytes external = 7 bytes total

對打印結果，詳細解釋一下：

2.1、對象頭(Object Header)

Object Header 是 MarkWord 和 Class Pointer 組成的，后面會詳細解釋。

打印結果：占用 4+4+4=12 個 bytes。

2.2、實例數據(Interface Data)

對象實例數據包括了對象的所有成員變量，其大小由各個成員變量大小決定的。

當然，不包括靜態成員變量，因為它是在方法區維護的!

打印結果：可以看到 int L.i 和 boolean L.flag 就是實例數據，占用 4+1=5 個 bytes。

2.3、填充數據(Padding)

Java 對象占用空間是 8 字節對齊的，即所有 Java 對象占用 bytes 數必須是 8  的倍數,因為當我們從磁盤中取一個數據時，不會是一個字節的去讀，都是按照一整塊來讀取的，這一塊大小就是 8 個字節，所以為了完整，padding  的作用就是補充字節，保證對象是 8 字節的整數倍。

打印結果：可以看到(loss due to the next object alignment) 這個就是填充數據，占用 7個字節。

這樣的話，12+5+7=24 一共是 24 個 bytes，正好是 8 的倍數。

所以說，一個對象的內存布局是由對象頭、實例數據、填充數據組成的。

接下來：重點關注這個對象頭。

三、細說對象頭

上面提到了對象頭，直接看官網上的解釋，官網地址在文末：

3.1、對象頭(object header)

• object header:Common structure at the beginning of every GC-managed heap  object. (Every oop points to an object header.) Includes fundamental information  about the heap object's layout, type, GC state, synchronization state, and  identity hash code. Consists of two words. In arrays it is immediately followed  by a length field. Note that both Java objects and VM-internal objects have a  common object header format.

• 翻譯：在每個 gc 管理的堆對象開始處的公共結構。(每個 oop 都指向一個對象頭)包括關于堆對象的布局、類型、GC  狀態、同步狀態和標識哈希碼的基本信息。由兩個詞組成。在數組中，緊隨其后的是長度字段。注意，Java 對象和 vm 內部對象都有一個通用的對象頭格式。

3.2、Klass Point

• The second word of every object header. Points to another object (a  metaobject) which describes the layout and behavior of the original object. For  Java objects, the "klass" contains a C++ style "vtable".

• 翻譯：每個對象頭的第二個字。指向另一個對象(元對象)，該對象描述原始對象的布局和行為。對于 Java 對象，“klass”包含一個  c++風格的“虛函數表”。

3.3、Mark Word

• The first word of every object header. Usually a set of bitfields including  synchronization state and identity hash code. May also be a pointer (with  characteristic low bit encoding) to synchronization related information. During  GC, may contain GC state bits.

• 翻譯：每個對象頭的第一個字。通常是一組位域，包括同步狀態和身份哈希碼。也可能是同步相關信息的指針(具有低比特編碼特征)。在 GC 期間，可能包含 GC  狀態位。

總結一下：其實對象頭就是 MarkWord 和 Klass Point 組成的。MarkWord 是用來存儲對象的 hashCode、鎖信息或分代年齡或  GC 標志等信息。Klass Point 是對象指向它的類元數據的指針，虛擬機通過這個指針來確定這個對象是哪個類的實例。

那么問題來了!!

問題：那上面說的 MarkWord 是存儲的 hashcode、鎖信息或分代年齡或 GC 標志是在那定義的呢?

你可以下載 OpenJDK 的源碼，在 markOop.hpp 的文件中可以看到 Mark Word 的狀態信息：

markOop.hpp

可以看到還是寫的非常清晰的，畫圖總結一下：

Mark Word空間

四、synchronized 深入分析

把 Test.java 編譯為 Test.class ，并在對應目錄下執行javap -v Test.class  這個命令，你能看到對應的字節碼，如下：

字節碼

上圖可以看到 JVM 對于同步方法和同步代碼塊的處理方式是不同的。

對于同步代碼塊：采用 monitorenter 和 monitorexit 兩個指令來實現同步。

monitorenter 指令可以理解為加鎖，monitorexit 可以理解為釋放鎖。

進入 monitorenter 指令后，線程將持有 Monitor 對象，退出 monitorenter 指令后，線程將釋放該 Monitor  對象。

對于方法：出現了ACC_SYNCHRONIZED 標識。

當出現了 ACC_SYNCHRONIZED 標識符的時候，Jvm 會隱式調用 monitorenter 和 monitorexit。在執行同步方法前會調用  monitorenter，在執行完同步方法后會調用 monitorexit，釋放 Monitor 對象。

你可以發現，不管是同步代碼塊還是同步方法，都和 Monitor 對象有關系。

那么問題又來了!!

問題：這個 Monitor 對象是啥呢?monitorenter 和 monitorexit 又是什么呢?

4.1、monitorenter

直接看 JVM 規范里對它的描述，地址在文末：

• Each object is associated with a monitor. A monitor is locked if and only if  it has an owner. The thread that executes monitorenter attempts to gain  ownership of the monitor associated with objectref, as follows:

• If the entry count of the monitor associated with objectref is zero, the  thread enters the monitor and sets its entry count to one. The thread is then  the owner of the monitor.

• If the thread already owns the monitor associated with objectref, it reenters  the monitor, incrementing its entry count.

• If another thread already owns the monitor associated with objectref, the  thread blocks until the monitor's entry count is zero, then tries again to gain  ownership.

• 翻譯：每一個對象都會和一個監視器 Monitor 關聯。監視器被占用時會被鎖住，其他線程無法來獲取該 Monitor。當 JVM  執行某個線程的某個方法內部的 onitorenter 時，它會嘗試去獲取當前對象對應的 Monitor 的所有權。

執行過程如下：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 若 Monior 的進入數為 0，線程可以進入 Monitor，并將 monitor 的進入數置為 1。當前線程成為 Monitor 的 owner  擁有者。

3. 若線程已擁有 Monitor 的所有權，允許它重入 Monitor，則進入 Monitor 的進入數加 1。

4. 若其他線程已經占有 Monitor 的所有權，那么當前嘗試獲取 Monitor 的所有權的線程會被阻塞，直到 Monitor 的進入數變為  0，才能重新嘗試獲取 Monitor 的所有權。

4.2、monitorexit

看 JVM 規范里對它的描述，地址在文末：

• The thread that executes monitorexit must be the owner of the monitor  associated with the instance referenced by objectref.

• The thread decrements the entry count of the monitor associated with  objectref. If as a result the value of the entry count is zero, the thread exits  the monitor and is no longer its owner. Other threads that are blocking to enter  the monitor are allowed to attempt to do so.

執行過程如下：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 能執行 monitorexit 指令的線程一定是擁有當前對象的 Monitor 的所有權的線程。

3. 執行 monitorexit 時會將 Monitor 的進入數減 1。當 Monitor 的進入數減為 0 時，當前線程退出 Monitor，不再擁有  Monitor 的所有權，此時其他被這個 Monitor 阻塞的線程可以嘗試去獲取這個 Monitor 的所有權。

4.3、Monitor 監視器

每個對象都會關聯一個 Monitor 對象，也叫做監視器。

在 HotSpot 虛擬機中，Monitor 是由 ObjectMonitor 實現的。其源碼是用 c++來實現的，位于 HotSpot 虛擬機源碼  ObjectMonitor.hpp 文件中(路徑：src/share/vm/runtime/objectMonitor.hpp)

ObjectMonitor 主要數據結構如下：

ObjectMonitor() {     _header       = NULL;     _count        = 0;     _waiters      = 0,     _recursions   = 0;     //線程的重入次數     _object       = NULL;  //存儲該monitor對象     _owner        = NULL;  //標識擁有該monitor的線程     _WaitSet      = NULL;  //處于wait狀態的線程會被加入到_WaitSet     _WaitSetLock  = 0 ;     _Responsible  = NULL ;     _succ         = NULL ;     _cxq          = NULL ; //多線程競爭鎖時的單向列表     FreeNext      = NULL ;     _EntryList    = NULL ; //等待獲取鎖的線程，會放到這里     _SpinFreq     = 0 ;     _SpinClock    = 0 ;     OwnerIsThread = 0 ;   }

看到這里，我相信你就能明白為啥之前要解釋對象內存布局、對象頭，因為這三者之間是有對應關系的。

畫圖總結一下：

可以看到 ObjectMonitor 的數據結構中包含：_owner、_WaitSet 和_EntryList。

它們之間的關系轉換如下：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 當多個線程同時訪問同一段代碼塊或者某個同步方法的時候，這些線程會首先被放進_EntryList 隊列中，處于 blocked  狀態的線程，都會放入該隊列中。

3. 當某個線程獲取到對象的 Monitor 時，此時就就可以進入 running 狀態，執行代碼邏輯，此時，ObjectMonitor 對象的_owner  指向當前線程，_count 加 1 表示當前對象鎖被一個線程獲取。而沒有獲取到鎖的線程，會再次進入_EntryList 被掛起。

4. 當 running 狀態的線程調用 wait()方法，當前線程就會釋放 Monitor 對象，進入 waiting 狀態，ObjectMonitor  對象的_owner 變為 null，_count 減 1，同時線程進入_WaitSet 隊列，直到有線程調用  notify()方法喚醒該線程，則該線程再次進入_EntryList 隊列，直到再次競爭到鎖再進入_owner 區。

5. 如果當前線程執行完畢，那么也釋放 monitor 對象，ObjectMonitor 對象的_owner 變為 null，_count 減 1。

這個過程大致就是在 JDK6 之前 實現的原理。

但是，JDK6 之前，synchronized關鍵字的效率是非常低的。

原因如下：

Monitor 對象是依靠底層操作系統的 Mutex Lock 來實現互斥的，線程申請 Mutex 成功，則持有該 Mutex，其它線程將無法獲取到該  Mutex。

既然 Mutex Lock  涉及到底層操作系統，那這個時候就存在操作系統用戶態和核心態的轉換，這種切換會消耗大量的系統資源，因為用戶態與內核態都有各自專用的內存空間，專用的寄存器等，用戶態切換至內核態需要傳遞給許多變量、參數給內核，內核也需要保護好用戶態在切換時的一些寄存器值、變量等。

所以，在JDK 6 之后，從Jvm層面進行了優化，分為了偏向鎖，輕量級鎖，自旋鎖，重量級鎖。

五、鎖升級

下面就依此來說鎖是如何一步步升級的。

5.1、偏向鎖

1、什么是偏向鎖?

HotSpot作者經過研究實踐發現，在大多數情況下，鎖不僅不存在多線程競爭，而且總是由同一線程多次獲得，為了讓線程獲得鎖的代價更低，引進了偏向鎖。

偏向鎖的“偏”，就是偏心的“偏”，它的意思是這個鎖會偏向于第一個獲得它的線程，會在對象頭存儲鎖偏向的線程ID，以后該線程進入和退出同步塊時只需要檢查是否為偏向鎖、鎖標志位以及ThreadID即可。

偏向鎖Mark Word

不過一旦出現多個線程競爭時必須撤銷偏向鎖，所以撤銷偏向鎖消耗的性能必須小于之前節省下來的CAS原子操作的性能消耗，不然就得不償失了。

2、偏向鎖原理

無鎖到偏向鎖的轉換流程圖：

偏向鎖流程圖

參數：-XX:+UseBiasedLocking 開啟偏向鎖

簡單來說：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 線程訪問同步代碼塊，使用 CAS 操作將 Thread ID 放到 MarkWord 當中

3. 如果線程 CAS 成功，此時線程就會獲取到偏向鎖

4. 如果線程 CAS 失敗，證明已經有別的線程持有鎖，這個時候啟動偏向鎖撤銷，執行下面的操作

3、偏向鎖的撤銷

流程如下：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 偏向鎖的撤銷動作必須等待全局安全點

3. 暫停原持有偏向鎖的線程

4. 將 Thread ID置為null，使其變成無鎖狀態

5. 恢復原持有偏向鎖線程，開始進行輕量級加鎖流程

5.2 輕量級鎖

1、什么是輕量級鎖?

輕量級鎖是JDK  6之中加入的鎖機制，它名字中的“輕量級”是相對于使用monitor的傳統鎖而言的，因此傳統的鎖機制就稱為“重量級”鎖。需要強調一點的是，輕量級鎖并不是用來代替重量級鎖的。

引入輕量級鎖的目的：在多線程交替執行同步塊的情況下，盡量避免重量級鎖引起的性能消耗，但是如果多個線程在同一時刻進入臨界區，會導致輕量級鎖膨脹升級重量級鎖，所以輕量級鎖的出現并非是要替代重量級鎖。

2、輕量級鎖原理

當關閉偏向鎖功能或者多個線程競爭偏向鎖導致偏向鎖升級為輕量級鎖，則會嘗試獲取輕量級鎖。

流程圖如下：

輕量級鎖升級過程

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 判斷當前對象是否處于無鎖狀態(hashcode、0、01)，如果是，則JVM首先將在當前線程的棧幀中建立一個名為鎖記錄(Lock  Record)的空間，用于存儲鎖對象目前的 Mark Word 的拷貝(官方把這份拷貝加了一個 Displaced 前綴，即Displaced Mark  Word)，將對象的 Mark Word復制到棧幀中的 Lock Record 中，將 Lock Reocrd 中的 owner 指向當前對象。

3. JVM利用CAS操作嘗試將對象的 Mark Word 更新為指向 Lock Record 的指針，如果成功，表示競爭到鎖，則將鎖標志位變成  00，執行同步操作。

4. 如果失敗，則判斷當前對象的Mark  Word是否指向當前線程的棧幀，如果是，則表示當前線程已經持有當前對象的鎖，則直接執行同步代碼塊;否則只能說明該鎖對象已經被其他線程搶占了，這時輕量級鎖需要膨脹為重量級鎖，鎖標志位變成10，后面等待的線程將會進入阻塞狀態。

5.3 自旋鎖

1、為什么會有自旋鎖?

前面聊 monitor 實現鎖的時候，知道 monitor 會阻塞和喚醒線程，線程的阻塞和喚醒需要 CPU 從用戶態轉為核心態，頻繁的阻塞和喚醒對 CPU  來說是一件負擔很重的工作，這些操作給系統的并發性能帶來了很大的壓力。

同時，虛擬機的開發團隊也注意到在許多應用上，共享數據的鎖定狀態只會持續很短的一段時間，為了這段時間阻塞和喚醒線程并不值得。

如果物理機器有一個以上的處理器，能讓兩個或以上的線程同時并行執行，我們就可以讓后面請求鎖的那個線程“稍等一下”，但不放棄處理器的執行時間，看看持有鎖的線程是否很快就會釋放鎖。為了讓線程等待，我們只需讓線程執行一個循環(自旋)  , 這就是所謂的自旋鎖。

2、自旋鎖的優缺點

自旋等待不能代替阻塞，且先不說對處理器數量的要求，自旋等待本身雖然避免了線程切換的開銷，但它是要占用處理器時間的。

如果鎖被占用的時間很短，自旋等待的效果就會非常好，反之，如果鎖被占用的時間很長。那么自旋的線程只會白白消耗處理器資源，而不會做任何有用的工作，反而會帶來性能上的浪費。

所以，自旋等待的時間必須要有一定的限度，如果在多線程交替執行同步塊的情況下，可以避免重量級鎖引起的性能消耗。

自旋超過了限定的次數仍然沒有成功獲得鎖，就應當使用傳統的方式去掛起線程了。自旋次數的默認值是10次，你可以使用參數 -XX : PreBlockSpin  來更改。

5.4 適應性自旋鎖

在JDK 6中引入了自適應的自旋鎖。自適應意味著自旋的時間不再固定了，而是由前一次在同一鎖上的自選時間及鎖的擁有者的狀態來決定。

如果在同一個對象鎖上，自旋等待剛剛成功獲得過鎖，并且持有鎖的線程正在運行中，那虛擬機就會認為這次自旋也很有可能再次成功，進而它將允許自旋等待持續相對更長的時間，比如100次循環。

如果，對于某個鎖，自旋很少成功獲得過，那在以后要獲取這個鎖時可能會省略掉自旋過程，避免浪費服務器處理資源。

有了自適應自旋鎖，虛擬機對程序的狀況預測就會變得準確，性能也會有所提升。

感謝各位的閱讀，以上就是“如何掌握Synchronized關鍵字”的內容了，經過本文的學習后，相信大家對如何掌握Synchronized關鍵字這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！