如何掌握Synchronized關(guān)鍵字

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

一、synchronized的用法

1.1、三種使用方式

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 靜態(tài)方法

3. 非靜態(tài)方法

4. 代碼塊

代碼示例：

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

1.2、作用范圍

面試時經(jīng)常會問：synchronized 關(guān)鍵字鎖的是什么?或者說它的作用范圍是什么?

總結(jié)一下：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 非靜態(tài)方法鎖的是當(dāng)前對象 (就是 this)

3. 靜態(tài)方法鎖的是類對象 Test.class

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

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

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

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

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

• 可見性：執(zhí)行 synchronized 時，對應(yīng) lock 原子操作將會清空工作內(nèi)存中此變量的值，并重新 read  來刷新內(nèi)存，不會出現(xiàn)可見性的問題

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

二、對象內(nèi)存布局

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

其實是和對象內(nèi)存布局有關(guān)系。

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

示例代碼：

//1、需要導(dǎo)入包 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());     } }

打印出來的結(jié)果是這樣的：

 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

對打印結(jié)果，詳細(xì)解釋一下：

2.1、對象頭(Object Header)

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

打印結(jié)果：占用 4+4+4=12 個 bytes。

2.2、實例數(shù)據(jù)(Interface Data)

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

當(dāng)然，不包括靜態(tài)成員變量，因為它是在方法區(qū)維護(hù)的!

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

2.3、填充數(shù)據(jù)(Padding)

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

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

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

所以說，一個對象的內(nèi)存布局是由對象頭、實例數(shù)據(jù)、填充數(shù)據(jù)組成的。

接下來：重點關(guān)注這個對象頭。

三、細(xì)說對象頭

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

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 管理的堆對象開始處的公共結(jié)構(gòu)。(每個 oop 都指向一個對象頭)包括關(guān)于堆對象的布局、類型、GC  狀態(tài)、同步狀態(tài)和標(biāo)識哈希碼的基本信息。由兩個詞組成。在數(shù)組中，緊隨其后的是長度字段。注意，Java 對象和 vm 內(nèi)部對象都有一個通用的對象頭格式。

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++風(fēng)格的“虛函數(shù)表”。

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.

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

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

那么問題來了!!

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

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

markOop.hpp

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

Mark Word空間

四、synchronized 深入分析

把 Test.java 編譯為 Test.class ，并在對應(yīng)目錄下執(zhí)行javap -v Test.class  這個命令，你能看到對應(yīng)的字節(jié)碼，如下：

字節(jié)碼

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

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

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

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

對于方法：出現(xiàn)了ACC_SYNCHRONIZED 標(biāo)識。

當(dāng)出現(xiàn)了 ACC_SYNCHRONIZED 標(biāo)識符的時候，Jvm 會隱式調(diào)用 monitorenter 和 monitorexit。在執(zhí)行同步方法前會調(diào)用  monitorenter，在執(zhí)行完同步方法后會調(diào)用 monitorexit，釋放 Monitor 對象。

你可以發(fā)現(xiàn)，不管是同步代碼塊還是同步方法，都和 Monitor 對象有關(guān)系。

那么問題又來了!!

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

4.1、monitorenter

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

• 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.

• 翻譯：每一個對象都會和一個監(jiān)視器 Monitor 關(guān)聯(lián)。監(jiān)視器被占用時會被鎖住，其他線程無法來獲取該 Monitor。當(dāng) JVM  執(zhí)行某個線程的某個方法內(nèi)部的 onitorenter 時，它會嘗試去獲取當(dāng)前對象對應(yīng)的 Monitor 的所有權(quán)。

執(zhí)行過程如下：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 若 Monior 的進(jìn)入數(shù)為 0，線程可以進(jìn)入 Monitor，并將 monitor 的進(jìn)入數(shù)置為 1。當(dāng)前線程成為 Monitor 的 owner  擁有者。

3. 若線程已擁有 Monitor 的所有權(quán)，允許它重入 Monitor，則進(jìn)入 Monitor 的進(jìn)入數(shù)加 1。

4. 若其他線程已經(jīng)占有 Monitor 的所有權(quán)，那么當(dāng)前嘗試獲取 Monitor 的所有權(quán)的線程會被阻塞，直到 Monitor 的進(jìn)入數(shù)變?yōu)? 0，才能重新嘗試獲取 Monitor 的所有權(quán)。

4.2、monitorexit

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

• 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.

執(zhí)行過程如下：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 能執(zhí)行 monitorexit 指令的線程一定是擁有當(dāng)前對象的 Monitor 的所有權(quán)的線程。

3. 執(zhí)行 monitorexit 時會將 Monitor 的進(jìn)入數(shù)減 1。當(dāng) Monitor 的進(jìn)入數(shù)減為 0 時，當(dāng)前線程退出 Monitor，不再擁有  Monitor 的所有權(quán)，此時其他被這個 Monitor 阻塞的線程可以嘗試去獲取這個 Monitor 的所有權(quán)。

4.3、Monitor 監(jiān)視器

每個對象都會關(guān)聯(lián)一個 Monitor 對象，也叫做監(jiān)視器。

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

ObjectMonitor 主要數(shù)據(jù)結(jié)構(gòu)如下：

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

看到這里，我相信你就能明白為啥之前要解釋對象內(nèi)存布局、對象頭，因為這三者之間是有對應(yīng)關(guān)系的。

畫圖總結(jié)一下：

可以看到 ObjectMonitor 的數(shù)據(jù)結(jié)構(gòu)中包含：_owner、_WaitSet 和_EntryList。

它們之間的關(guān)系轉(zhuǎn)換如下：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

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

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

4. 當(dāng) running 狀態(tài)的線程調(diào)用 wait()方法，當(dāng)前線程就會釋放 Monitor 對象，進(jìn)入 waiting 狀態(tài)，ObjectMonitor  對象的_owner 變?yōu)?null，_count 減 1，同時線程進(jìn)入_WaitSet 隊列，直到有線程調(diào)用  notify()方法喚醒該線程，則該線程再次進(jìn)入_EntryList 隊列，直到再次競爭到鎖再進(jìn)入_owner 區(qū)。

5. 如果當(dāng)前線程執(zhí)行完畢，那么也釋放 monitor 對象，ObjectMonitor 對象的_owner 變?yōu)?null，_count 減 1。

這個過程大致就是在 JDK6 之前 實現(xiàn)的原理。

但是，JDK6 之前，synchronized關(guān)鍵字的效率是非常低的。

原因如下：

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

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

所以，在JDK 6 之后，從Jvm層面進(jìn)行了優(yōu)化，分為了偏向鎖，輕量級鎖，自旋鎖，重量級鎖。

五、鎖升級

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

5.1、偏向鎖

1、什么是偏向鎖?

HotSpot作者經(jīng)過研究實踐發(fā)現(xiàn)，在大多數(shù)情況下，鎖不僅不存在多線程競爭，而且總是由同一線程多次獲得，為了讓線程獲得鎖的代價更低，引進(jìn)了偏向鎖。

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

偏向鎖Mark Word

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

2、偏向鎖原理

無鎖到偏向鎖的轉(zhuǎn)換流程圖：

偏向鎖流程圖

參數(shù)：-XX:+UseBiasedLocking 開啟偏向鎖

簡單來說：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

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

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

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

3、偏向鎖的撤銷

流程如下：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

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

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

4. 將 Thread ID置為null，使其變成無鎖狀態(tài)

5. 恢復(fù)原持有偏向鎖線程，開始進(jìn)行輕量級加鎖流程

5.2 輕量級鎖

1、什么是輕量級鎖?

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

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

2、輕量級鎖原理

當(dāng)關(guān)閉偏向鎖功能或者多個線程競爭偏向鎖導(dǎo)致偏向鎖升級為輕量級鎖，則會嘗試獲取輕量級鎖。

流程圖如下：

輕量級鎖升級過程

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

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

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

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

5.3 自旋鎖

1、為什么會有自旋鎖?

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

同時，虛擬機(jī)的開發(fā)團(tuán)隊也注意到在許多應(yīng)用上，共享數(shù)據(jù)的鎖定狀態(tài)只會持續(xù)很短的一段時間，為了這段時間阻塞和喚醒線程并不值得。

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

2、自旋鎖的優(yōu)缺點

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

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

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

自旋超過了限定的次數(shù)仍然沒有成功獲得鎖，就應(yīng)當(dāng)使用傳統(tǒng)的方式去掛起線程了。自旋次數(shù)的默認(rèn)值是10次，你可以使用參數(shù) -XX : PreBlockSpin  來更改。

5.4 適應(yīng)性自旋鎖

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

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

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

有了自適應(yīng)自旋鎖，虛擬機(jī)對程序的狀況預(yù)測就會變得準(zhǔn)確，性能也會有所提升。

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