一、前言

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

二、Java 對象鎖的使用方式

2.1 實例方法的同步

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

2.2 靜態方法的同步

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

2.3 代碼塊的同步

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

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

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

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

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

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

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

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

重新獲得object 對象鎖繼續執行。Object類方法說明：

三、Android對象內存結構

3.1 對象內存結構

一個類的實例對象內存主要由3部分組成：

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

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

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

3.2 monitor_ 字段分析

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

操作函數中SetLockWord和CasLockWord函數的入參或GetLockWord函數的返回值都包含LockWord 變量，對monitor_ 字段的操作是通過LockWord 的值進行的。

下面再來看LockWord 定義：

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

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

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

fat lock狀態下31-30 bit 為01，當對象鎖在thin lock狀態，且有新的(非owner)線程與其競爭，經過適當的等待期（sched_yield調用、循環獲取thin lock 狀態）后依然無法拿到鎖，則轉換為fat lock 狀態，并為該對象分配一個Monitor 資源。

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

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

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

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

四、對象鎖代碼分析

4.1 首先我們看一段代碼

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

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

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

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

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

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

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

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

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

main 函數的指令信息如下：

對部分指令解析如下:

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

4.3．Object.wait() 流程分析

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

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

首先構造了一個操作obj 的Handle對象h_obj，通過ObjectWaitStart 函數通知jvmti 調試系統發生了JVMTI_EVENT_MONITOR_WAIT 事件。

JVMTI（JVM Tool Interface）是 Java 虛擬機所提供的 native 編程接口，可以用來開發并監控虛擬機，可以查看JVM內部的狀態，并控制JVM應用程序的執行。可實現的功能包括但不限于：調試、監控、線程分析、覆蓋率分析工具等。

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

1).hash 或unlocked 狀態:

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

2).thin lock 狀態：

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

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

4.4 Object.notify() 流程分析

這里我們直接分析DoNotify 函數：

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

1) hash 或unlocked 狀態 :

拋出IllegalMonitorStateException 異常。

2).thin lock 狀態：

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

3).fat lock 狀態：

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

4.5monitor-enter 流程分析

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

下面來分析Monitor類的靜態方法MonitorEnter 函數。

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

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

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

當鎖狀態為thin lock 狀態時，首先獲取鎖的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 區域無法存儲)，則調用InflateThinLocked 函數對thin lock 進行膨脹。

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

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

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

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

當鎖狀態已經是hash 狀態時，直接對鎖進行膨脹。

下面看鎖膨脹的過程：

thin lock 的膨脹有兩種情形：

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

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

再看Inflate 的過程：

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

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

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

再看Monitor::Lock的過程：

該函數的實現較長，省去調試相關的代碼。

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

TryLock 函數主要是通過Mutex的函數實現一定的自旋等待，并設置鎖的狀態為線程持有的狀態。

monitor_lock_.ExclusiveLock(self);在Mutex 的ExclusiveLock函數中通過futex 系統調用實現了線程的阻塞，futex調用代碼如下。

4.6 monitor-exit 流程分析

解釋執行和機器碼執行模式都會調用到MonitorExit 函數。

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

當LockWord 的狀態為thin lock 狀態時，有下面兩種情況：

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

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

當LockWord 的狀態為fat lock狀態時，獲取該對象關聯的Monitor 對象，并調用Unlock 函數

在Unlock 函數中lock_count 為0，說明該線程不在持有該鎖，通過SignalWaiterAndReleaseMonitorLock 喚醒阻塞在該鎖上的線程。

五、總結

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

審核編輯：劉清