一、前言

編程過程中經(jīng)常會(huì)遇到線程的同步問題，Java 中對(duì)同步問題的解決方案比較多（synchronized、JUC、原子操作、volatile、條件變量等），其中synchronized 最方便、簡單易用，也是java 編程中使用最多的臨界區(qū)保護(hù)方案。本文主要講述對(duì)象鎖的相關(guān)知識(shí)，詳細(xì)介紹synchronized 和Object 的關(guān)鍵方法的虛擬機(jī)實(shí)現(xiàn)原理。

二、Java 對(duì)象鎖的使用方式

2.1 實(shí)例方法的同步

synchronized 修飾實(shí)例方法，該同步僅對(duì)當(dāng)前對(duì)象的該方法起作用，同一時(shí)間只能有一個(gè)線程可以進(jìn)入該對(duì)象的此方法。對(duì)于不同對(duì)象的此函數(shù)，無法做到互斥保護(hù)。

2.2 靜態(tài)方法的同步

synchronized 修飾靜態(tài)方法，該同步對(duì)當(dāng)前類對(duì)象的該方法起作用，同一時(shí)間只能有一個(gè)線程可以進(jìn)入該方法。

2.3 代碼塊的同步

在大多少情況下，并不需要對(duì)整個(gè)方法進(jìn)行保護(hù)，當(dāng)synchronized 修飾代碼塊時(shí)，該代碼塊的訪問依賴于object 對(duì)象鎖的互斥訪問，同一時(shí)間只能有一個(gè)線程持有object 對(duì)象鎖。

更準(zhǔn)確的來講，synchronized 關(guān)鍵字是依賴于對(duì)象鎖而生效的，每個(gè)synchronized 同步塊開始的地方都會(huì)生成monitor-enter obj指令，同步塊結(jié)束的地方生成monitor-exit obj 的指令，其中obj 為用于控制互斥訪問的對(duì)象。同一時(shí)間只能有一個(gè)線程持有obj 的對(duì)象鎖。在2.1 中synchronized 依賴的是實(shí)列對(duì)象，2.2 中synchronized 依賴的是類對(duì)象，2.3 中synchronized 依賴的是object 對(duì)象。

當(dāng)一個(gè)對(duì)象控制多個(gè)代碼塊時(shí)，多個(gè)代碼塊也是互斥訪問，如下面代碼：

代碼塊①和代碼塊② 雖然在兩個(gè)函數(shù)中，但是synchronized 依賴的對(duì)象都為object，這兩個(gè)代碼塊也是互斥訪問。

2.4 Object ?wait() 和notify() 使用方法

Object 作為所有類的基類，都實(shí)現(xiàn)了object方法。典型的用法如下：

thread 1持有object 對(duì)象鎖，并調(diào)用object.wait() 方法后，則該線程進(jìn)入WAITING狀態(tài)，并釋放object 對(duì)象鎖，等待其它線程來喚醒它。

當(dāng)thread 2 持有object 對(duì)象鎖，并調(diào)用object.notify()方法后，喚醒thread 1，thread 1

重新獲得object 對(duì)象鎖繼續(xù)執(zhí)行。Object類方法說明：

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【749907784】整理了一些個(gè)人覺得比較好的學(xué)習(xí)書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書、實(shí)戰(zhàn)項(xiàng)目及代碼)? ?

3.1 對(duì)象內(nèi)存結(jié)構(gòu)

一個(gè)類的實(shí)例對(duì)象內(nèi)存主要由3部分組成：

1). 對(duì)象頭：對(duì)象頭包括kclass_和monitor_兩個(gè)字段，其中kclass_ 存放指向類對(duì)象的指針，通過該指針可以找到該對(duì)象對(duì)應(yīng)的類，monitor_ 用于存放對(duì)象運(yùn)行時(shí)的標(biāo)識(shí)數(shù)據(jù)，例如: GC 標(biāo)志位、哈希碼、鎖狀態(tài)等信息,后面詳細(xì)分析。

2). 實(shí)例數(shù)據(jù)，該部分存放實(shí)例變量值，父類實(shí)例變量值在前，子類在后，且實(shí)例變量值按照如下順序進(jìn)行排序：

3).對(duì)齊填充，對(duì)象在內(nèi)存中是按照8byte 對(duì)齊的，如果實(shí)例數(shù)據(jù)部分沒有按照8byte對(duì)齊，則填充為8byte 對(duì)齊。

3.2 monitor_ 字段分析

monitor_ 字段定義在art/runtime/mirror/object.h，類型為uint32_t，主要有下面3個(gè)操作函數(shù)。

操作函數(shù)中SetLockWord和CasLockWord函數(shù)的入?yún)⒒騁etLockWord函數(shù)的返回值都包含LockWord 變量，對(duì)monitor_ 字段的操作是通過LockWord 的值進(jìn)行的。

下面再來看LockWord 定義：

LockWord 類的定義在art/runtime/lock_word.h 文件中，從注釋中可以看到LockWord的使用主要有4種狀態(tài)，如下：

LockWord 的設(shè)計(jì)非常精妙，一個(gè)32 位數(shù)據(jù)的每一位都充分利用，而且很好的區(qū)分了不同狀態(tài)。下面對(duì)各狀態(tài)進(jìn)行詳細(xì)說明：

1. unlocked/thin 狀態(tài)下31-30 bit 為00，默認(rèn)狀態(tài)下為unlocked 狀態(tài)，當(dāng)對(duì)象進(jìn)行線程同步時(shí)變成thin lock 狀態(tài)，27-16bit 記錄了thin lock重入的次數(shù)，15-0 bit 記錄了持有該thin lock的線程ID。

2. fat lock狀態(tài)下31-30 bit 為01，當(dāng)對(duì)象鎖在thin lock狀態(tài)，且有新的(非owner)線程與其競爭，經(jīng)過適當(dāng)?shù)牡却冢╯ched_yield調(diào)用、循環(huán)獲取thin lock 狀態(tài)）后依然無法拿到鎖，則轉(zhuǎn)換為fat lock 狀態(tài)，并為該對(duì)象分配一個(gè)Monitor 資源。

3. hash state狀態(tài)下31-30 bit 為10，在27-0 bit 存儲(chǔ)對(duì)象的hash code，當(dāng)在其它模式下，hash code 會(huì)存儲(chǔ)在該對(duì)象關(guān)聯(lián)的Monitor 對(duì)象中。

4. forwarding address state 狀態(tài)下31-30 bit 為11，在concurrent copying GC 的copy 階段，當(dāng)一個(gè)對(duì)象被拷貝后，指向拷貝后的對(duì)象地址，當(dāng)線程訪問到該對(duì)象后，通過該轉(zhuǎn)發(fā)地址，訪問新的對(duì)象。

第29 位為mark bit，通過該bit位可以快速判斷是否標(biāo)記過，避免重復(fù)標(biāo)記。

第28 位為read barrier bit，如果對(duì)象LockWorkd的該bit 被設(shè)置，則在訪問該對(duì)象的成員時(shí)會(huì)進(jìn)入慢速路徑，判斷對(duì)象是不是需要更新，如果需要更新，則返回拷貝后的對(duì)象地址。

四、對(duì)象鎖代碼分析

4.1 首先我們看一段代碼

這段代碼比較簡單，主要有下面兩個(gè)核心點(diǎn)：

1). 在主線程執(zhí)行的過程中，用obj 對(duì)象進(jìn)行線程同步，并調(diào)用obj.wait()函數(shù)，使線程阻塞在了obj 對(duì)象鎖上等待喚醒。

2). main函數(shù)中創(chuàng)建匿名線程，該線程首先sleep 2000ms，然后喚醒阻塞在obj 對(duì)象鎖上線程。

4.2編譯TestDemo.java,命令如下：

1).Javac 將TestDemo.java 文件編譯生成TestDemo*.class文件,java 編譯過程中每個(gè)類會(huì)生成一個(gè)class 文件。

2).d8 命令將TestDemo*.class 文件通過編譯、重構(gòu)、重排、壓縮、混淆后生成對(duì)應(yīng)的dex （Dalvik Executable file）格式文件。

3).dexdump.exe命令可以查看dex 文件格式的詳細(xì)信息，如校驗(yàn)信息、dex 頭信息、生成dex 的CFG 信息、dex 的反匯編信息等，詳細(xì)使用方法可以通過dexdump.exe –help 命令查看

通過dexdump.exe –d classes.dex 查看反匯編

其中run 方法指令信息如下：

main 函數(shù)的指令信息如下：

對(duì)部分指令解析如下:

對(duì)于dex 指令詳細(xì)格式可以閱讀google 的官方文檔：

https://source.android.com/docs/core/runtime/dalvik-bytecode

本文重點(diǎn)分析monitor-enter、monitor-exit、Object.wait()、Object.notify()在虛擬機(jī)中的詳細(xì)實(shí)現(xiàn)。

4.3．Object.wait() 流程分析

Object.wait() 的調(diào)用關(guān)系如下：

Object 類是所有類的父類，任何類中都可以調(diào)用public 的wait() 方法，最終調(diào)用到虛擬機(jī)的monitor.cc 文件的wait 靜態(tài)方法，

首先構(gòu)造了一個(gè)操作obj 的Handle對(duì)象h_obj，通過ObjectWaitStart 函數(shù)通知jvmti 調(diào)試系統(tǒng)發(fā)生了JVMTI_EVENT_MONITOR_WAIT 事件。

JVMTI（JVM Tool Interface）是 Java 虛擬機(jī)所提供的 native 編程接口，可以用來開發(fā)并監(jiān)控虛擬機(jī)，可以查看JVM內(nèi)部的狀態(tài)，并控制JVM應(yīng)用程序的執(zhí)行。可實(shí)現(xiàn)的功能包括但不限于：調(diào)試、監(jiān)控、線程分析、覆蓋率分析工具等。

首先獲得h_obj 對(duì)象的LockWord 字段，lock_word.GetState()函數(shù)獲得當(dāng)前的鎖狀態(tài)，主要有下面幾種情況：

1).hash 或unlocked 狀態(tài):

因?yàn)檎{(diào)用wait()方法必須持有對(duì)象鎖，所以不會(huì)出現(xiàn)這兩種狀態(tài)，如果出現(xiàn)則拋出IllegalMonitorStateException 異常。

2).thin lock 狀態(tài)：

當(dāng)持有該對(duì)象鎖的線程不是要wait 的線程，也拋出IllegalMonitorStateException 異常，當(dāng)持有鎖的線程與要wait 的線程一致，這時(shí)需要將thin lock inflate 為fat lock，inflate 的過程在monitor-enter 指令分析中分析。

當(dāng)對(duì)象鎖inflate 為fat lock 狀態(tài)后，調(diào)用Monitor 對(duì)象的實(shí)例方法Wait讓線程進(jìn)入sleep 狀態(tài)等待。

4.4 Object.notify() 流程分析

這里我們直接分析DoNotify 函數(shù)：

通過lock_word.GetState() 獲得當(dāng)前obj 對(duì)象的鎖狀態(tài)，主要有下面情況：

1) hash 或unlocked 狀態(tài) :

拋出IllegalMonitorStateException 異常。

2).thin lock 狀態(tài)：

當(dāng)持有該對(duì)象鎖的線程不是要notify 的線程，也拋出IllegalMonitorStateException 異常，當(dāng)持有鎖的線程與要notify 的線程一致，這時(shí)說明沒有需要通知喚醒的線程，直接返回。

3).fat lock 狀態(tài)：

在Object.notify() 流程中參數(shù)notify_all 為false，則直接調(diào)用mon->Notify(self);通知喚醒等待線程。

4.5monitor-enter 流程分析

對(duì)于解釋執(zhí)行和機(jī)器碼執(zhí)行模式，最終都會(huì)調(diào)用到art/runtime/mirror/object-inl.h 文件Object 對(duì)象的MonitorEnter 函數(shù)。

下面來分析Monitor類的靜態(tài)方法MonitorEnter 函數(shù)。

FakeLock 主要用于線程安全性檢查，主要在編譯期檢測。

kExtraSpinIters 定義了當(dāng)對(duì)象鎖被其它線程持有且為thin lock 時(shí)，競爭線程循環(huán)獲取鎖的次數(shù)。

通過lock_word.GetState() 獲取鎖狀態(tài)，當(dāng)鎖狀態(tài)為unlocked 狀態(tài)時(shí)，轉(zhuǎn)換為thin lock 狀態(tài)，并通過cas 操作更新lock count。

當(dāng)鎖狀態(tài)為thin lock 狀態(tài)時(shí)，首先獲取鎖的owner 線程id，如果owner id 與競爭線程id 一致，則有下面兩種情況：

1. 如果lock count加1小于等于(1<<12)-1(4095)時(shí)，將lock count+1 更新lock count。

2. 如果lock count加1大于(1<<12)-1時(shí)(lock count 區(qū)域無法存儲(chǔ))，則調(diào)用InflateThinLocked 函數(shù)對(duì)thin lock 進(jìn)行膨脹。

Atrace* 相關(guān)的函數(shù)主要用于systrace 相關(guān)信息的打印，trylock 在這里為false。

當(dāng)鎖狀態(tài)為thin lock 狀態(tài)且鎖的owner 線程id 與競爭線程id 不一致，則做一定的等待。

runtime->GetMaxSpinsBeforeThinLockInflation() 的值為50 ，也就是說執(zhí)行100 次的循環(huán)判斷鎖狀態(tài)后，再執(zhí)行50次的sched_yield() 后還未獲得鎖資源，如果還未拿到鎖，則對(duì)該鎖進(jìn)行膨脹。sched_yield() 會(huì)主動(dòng)讓出當(dāng)前線程的執(zhí)行權(quán)限，并在某個(gè)時(shí)間后恢復(fù)執(zhí)行。

當(dāng)鎖狀態(tài)已經(jīng)是fat lock 狀態(tài)，通過lock_word.FatLockMonitor(); 獲取Monitor 對(duì)象，并通過Monitor 對(duì)象的Lock 函數(shù)讓線程進(jìn)入等待狀態(tài)。

當(dāng)鎖狀態(tài)已經(jīng)是hash 狀態(tài)時(shí)，直接對(duì)鎖進(jìn)行膨脹。

下面看鎖膨脹的過程：

thin lock 的膨脹有兩種情形：

1).lock count 的值超過了4095，這時(shí)鎖的owner 為當(dāng)前線程，即直接通過Inflate 函數(shù)膨脹

2).鎖的owner不是當(dāng)前線程，通過SuspendThreadByThreadId 暫停鎖的owner 線程（主要是owner 線程和鎖膨脹線程都需要訪問對(duì)象的LockWord，避免競態(tài)問題），然后通過Inflate 進(jìn)行膨脹。膨脹完成后再喚醒鎖的owner 線程。

再看Inflate 的過程：

通過MonitorPool::CreateMonitor函數(shù)獲取一個(gè)Monitor 的對(duì)象m，并通過m->install(self)函數(shù)更新對(duì)象的LockWord字段，這時(shí)LockWord 字段信息包含fat lock 狀態(tài)、GC 狀態(tài)、MonitorId，然后將m 保存在monitor_list_ 中。

monitor_list_中存儲(chǔ)了當(dāng)前虛擬機(jī)使用的所有Monitor 對(duì)象。在GC 的過程中，通過該鏈表，訪問到Monitor 依賴的對(duì)象。如果對(duì)象變成垃圾對(duì)象，則回收該Monitor，否則更新Monitor 依賴的對(duì)象信息。

MonitorId 用于唯一標(biāo)識(shí)一個(gè)Monitor，生成的方法可以看monitor_pool.h 中的實(shí)現(xiàn)。

再看Monitor::Lock的過程：

該函數(shù)的實(shí)現(xiàn)較長，省去調(diào)試相關(guān)的代碼。

首先介紹Monitor 中最重要的成員monitor_lock_ ，它是Mutex 的實(shí)例，通過該實(shí)例實(shí)現(xiàn)鎖相關(guān)的核心邏輯。

TryLock 函數(shù)主要是通過Mutex的函數(shù)實(shí)現(xiàn)一定的自旋等待，并設(shè)置鎖的狀態(tài)為線程持有的狀態(tài)。

monitor_lock_.ExclusiveLock(self);在Mutex 的ExclusiveLock函數(shù)中通過futex 系統(tǒng)調(diào)用實(shí)現(xiàn)了線程的阻塞，futex調(diào)用代碼如下。

4.6 monitor-exit 流程分析

解釋執(zhí)行和機(jī)器碼執(zhí)行模式都會(huì)調(diào)用到MonitorExit 函數(shù)。

通過lock_word.GetState()獲取LockWord 狀態(tài)，當(dāng)狀態(tài)為hash 或unlocked 狀態(tài)時(shí)，通過FailedUnlock函數(shù)拋出異常。

當(dāng)LockWord 的狀態(tài)為thin lock 狀態(tài)時(shí)，有下面兩種情況：

1).鎖的owner 與當(dāng)前線程不一致，則出錯(cuò)拋出異常。

2).鎖的owner 與當(dāng)前線程為同一線程，當(dāng)鎖有重入時(shí)，則將lock count -1，否則設(shè)置為unlocked 狀態(tài)。

當(dāng)LockWord 的狀態(tài)為fat lock狀態(tài)時(shí)，獲取該對(duì)象關(guān)聯(lián)的Monitor 對(duì)象，并調(diào)用Unlock 函數(shù)

在Unlock 函數(shù)中l(wèi)ock_count 為0，說明該線程不在持有該鎖，通過

SignalWaiterAndReleaseMonitorLock 喚醒阻塞在該鎖上的線程。

五、總結(jié)

本文簡單的闡述了對(duì)象鎖的使用方式，對(duì)象在內(nèi)存中的結(jié)構(gòu)，并對(duì)對(duì)象頭中關(guān)鍵成員LockWord 進(jìn)行了分析，最后介紹了synchronized、Object.wait()和Object.notify()在虛擬機(jī)中的實(shí)現(xiàn)流程。

原文作者：內(nèi)核工匠