詳細介紹synchronized和Object的關鍵方法和虛擬機實現(xiàn)原理

一、前言

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

二、Java 對象鎖的使用方式

2.1 實例方法的同步

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

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

synchronized 修飾靜態(tài)方法，該同步對當前類對象的該方法起作用，同一時間只能有一個線程可以進入該方法。

2.3 代碼塊的同步

在大多少情況下，并不需要對整個方法進行保護，當synchronized 修飾代碼塊時，該代碼塊的訪問依賴于object 對象鎖的互斥訪問，同一時間只能有一個線程持有object 對象鎖。

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

當一個對象控制多個代碼塊時，多個代碼塊也是互斥訪問，如下面代碼：

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

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

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

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

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

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

三、Android對象內(nèi)存結(jié)構(gòu)

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

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

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

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

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

3.2 monitor_ 字段分析

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

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

下面再來看LockWord 定義：

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

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

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

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

hash state狀態(tài)下31-30 bit 為10，在27-0 bit 存儲對象的hash code，當在其它模式下，hash code 會存儲在該對象關聯(lián)的Monitor 對象中。

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

第29 位為mark bit，通過該bit位可以快速判斷是否標記過，避免重復標記。

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

四、對象鎖代碼分析

4.1 首先我們看一段代碼

這段代碼比較簡單，主要有下面兩個核心點：

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

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

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

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

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

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

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

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

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

對部分指令解析如下:

本文重點分析monitor-enter、monitor-exit、Object.wait()、Object.notify()在虛擬機中的詳細實現(xiàn)。

4.3．Object.wait() 流程分析

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

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

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

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

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

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

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

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

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

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

4.4 Object.notify() 流程分析

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

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

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

拋出IllegalMonitorStateException 異常。

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

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

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

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

4.5monitor-enter 流程分析

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

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

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

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

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

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

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

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

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

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

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

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

當鎖狀態(tài)已經(jīng)是hash 狀態(tài)時，直接對鎖進行膨脹。

下面看鎖膨脹的過程：

thin lock 的膨脹有兩種情形：

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

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

再看Inflate 的過程：

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

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

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

再看Monitor::Lock的過程：

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

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

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

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

4.6 monitor-exit 流程分析

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

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

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

1).鎖的owner 與當前線程不一致，則出錯拋出異常。

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

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

在Unlock 函數(shù)中l(wèi)ock_count 為0，說明該線程不在持有該鎖，通過SignalWaiterAndReleaseMonitorLock 喚醒阻塞在該鎖上的線程。

五、總結(jié)

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

審核編輯：劉清