深入理解多執行緒（四）—— Moniter的實現原理
在深入理解多執行緒（一）——Synchronized的實現原理中介紹過關於Synchronize的實現原理，無論是同步方法還是同步程式碼塊，無論是ACC_SYNCHRONIZED還是monitorenter、monitorexit都是基於Monitor實現的，那麼這篇來介紹下什麼是Monitor。
作業系統中的管程
如果你在大學學習過作業系統，你可能還記得管程（monitors）在作業系統中是很重要的概念。同樣Monitor在java同步機制中也有使用。
管程 (英語：Monitors，也稱為監視器) 是一種程式結構，結構內的多個子程式（物件或模組）形成的多個工作執行緒互斥訪問共享資源。這些共享資源一般是硬體裝置或一群變數。管程實現了在一個時間點，最多隻有一個執行緒在執行管程的某個子程式。與那些通過修改資料結構實現互斥訪問的併發程式設計相比，管程實現很大程度上簡化了程式設計。 管程提供了一種機制，執行緒可以臨時放棄互斥訪問，等待某些條件得到滿足後，重新獲得執行權恢復它的互斥訪問。
Java執行緒同步相關的Moniter
在多執行緒訪問共享資源的時候，經常會帶來可見性和原子性的安全問題。為了解決這類執行緒安全的問題，Java提供了同步機制、互斥鎖機制，這個機制保證了在同一時刻只有一個執行緒能訪問共享資源。這個機制的保障來源於監視鎖Monitor，每個物件都擁有自己的監視鎖Monitor。
先來舉個例子，然後我們在上原始碼。我們可以把監視器理解為包含一個特殊的房間的建築物，這個特殊房間同一時刻只能有一個客人（執行緒）。這個房間中包含了一些資料和程式碼。
如果一個顧客想要進入這個特殊的房間，他首先需要在走廊（Entry Set）排隊等待。排程器將基於某個標準（比如 FIFO）來選擇排隊的客戶進入房間。如果，因為某些原因，該客戶客戶暫時因為其他事情無法脫身（執行緒被掛起），那麼他將被送到另外一間專門用來等待的房間（Wait Set），這個房間的可以可以在稍後再次進入那件特殊的房間。如上面所說，這個建築屋中一共有三個場所。
總之，監視器是一個用來監視這些執行緒進入特殊的房間的。他的義務是保證（同一時間）只有一個執行緒可以訪問被保護的資料和程式碼。
Monitor其實是一種同步工具，也可以說是一種同步機制，它通常被描述為一個物件，主要特點是：
物件的所有方法都被“互斥”的執行。好比一個Monitor只有一個執行“許可”，任一個執行緒進入任何一個方法都需要獲得這個“許可”，離開時把許可歸還。
通常提供singal機制：允許正持有“許可”的執行緒暫時放棄“許可”，等待某個謂詞成真（條件變數），而條件成立後，當前程序可以“通知”正在等待這個條件變數的執行緒，讓他可以重新去獲得執行許可。
監視器的實現
在Java虛擬機器(HotSpot)中，Monitor是基於C++實現的，由ObjectMonitor實現的，其主要資料結構如下：
ObjectMonitor() {
_header = NULL;
_count = 0;
_waiters = 0,
_recursions = 0;
_object = NULL;
_owner = NULL;
_WaitSet = NULL;
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;
FreeNext = NULL ;
_EntryList = NULL ;
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
}原始碼地址：objectMonitor.hpp
ObjectMonitor中有幾個關鍵屬性：
_owner：指向持有ObjectMonitor物件的執行緒
_WaitSet：存放處於wait狀態的執行緒佇列
_EntryList：存放處於等待鎖block狀態的執行緒佇列
_recursions：鎖的重入次數
_count：用來記錄該執行緒獲取鎖的次數
當多個執行緒同時訪問一段同步程式碼時，首先會進入_EntryList佇列中，當某個執行緒獲取到物件的monitor後進入_Owner區域並把monitor中的_owner變數設定為當前執行緒，同時monitor中的計數器_count加1。即獲得物件鎖。
若持有monitor的執行緒呼叫wait()方法，將釋放當前持有的monitor，_owner變數恢復為null，_count自減1，同時該執行緒進入_WaitSet集合中等待被喚醒。若當前執行緒執行完畢也將釋放monitor(鎖)並復位變數的值，以便其他執行緒進入獲取monitor(鎖)。如下圖所示
ObjectMonitor類中提供了幾個方法：
獲得鎖
void ATTR ObjectMonitor::enter(TRAPS) {
Thread * const Self = THREAD ;
void * cur ;
//通過CAS嘗試把monitor的`_owner`欄位設定為當前執行緒
cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ;
//獲取鎖失敗
if (cur == NULL) { assert (_recursions == 0 , "invariant") ;
assert (_owner == Self, "invariant") ;
// CONSIDER: set or assert OwnerIsThread == 1
return ;
}
// 如果舊值和當前執行緒一樣，說明當前執行緒已經持有鎖，此次為重入，_recursions自增，並獲得鎖。
if (cur == Self) {
// TODO-FIXME: check for integer overflow! BUGID 6557169.
_recursions ++ ;
return ;
}
// 如果當前執行緒是第一次進入該monitor，設定_recursions為1，_owner為當前執行緒
if (Self->is_lock_owned ((address)cur)) {
assert (_recursions == 0, "internal state error");
_recursions = 1 ;
// Commute owner from a thread-specific on-stack BasicLockObject address to
// a full-fledged "Thread *".
_owner = Self ;
OwnerIsThread = 1 ;
return ;
}
// 省略部分程式碼。
// 通過自旋執行ObjectMonitor::EnterI方法等待鎖的釋放
for (;;) {
jt->set_suspend_equivalent();
// cleared by handle_special_suspend_equivalent_condition()
// or java_suspend_self()
EnterI (THREAD) ;
if (!ExitSuspendEquivalent(jt)) break ;
//
// We have acquired the contended monitor, but while we were
// waiting another thread suspended us. We don't want to enter
// the monitor while suspended because that would surprise the
// thread that suspended us.
//
_recursions = 0 ;
_succ = NULL ;
exit (Self) ;
jt->java_suspend_self();
}
}
釋放鎖
void ATTR ObjectMonitor::exit(TRAPS) {
Thread * Self = THREAD ;
//如果當前執行緒不是Monitor的所有者
if (THREAD != _owner) {
if (THREAD->is_lock_owned((address) _owner)) { //
// Transmute _owner from a BasicLock pointer to a Thread address.
// We don't need to hold _mutex for this transition.
// Non-null to Non-null is safe as long as all readers can
// tolerate either flavor.
assert (_recursions == 0, "invariant") ;
_owner = THREAD ;
_recursions = 0 ;
OwnerIsThread = 1 ;
} else {
// NOTE: we need to handle unbalanced monitor enter/exit
// in native code by throwing an exception.
// TODO: Throw an IllegalMonitorStateException ?
TEVENT (Exit - Throw IMSX) ;
assert(false, "Non-balanced monitor enter/exit!");
if (false) {
THROW(vmSymbols::java_lang_IllegalMonitorStateException());
}
return;
}
}
// 如果_recursions次數不為0.自減
if (_recursions != 0) {
_recursions--; // this is simple recursive enter
TEVENT (Inflated exit - recursive) ;
return ;
}
//省略部分程式碼，根據不同的策略（由QMode指定），從cxq或EntryList中獲取頭節點，通過ObjectMonitor::ExitEpilog方法喚醒該節點封裝的執行緒，喚醒操作最終由unpark完成。
除了enter和exit方法以外，objectMonitor.cpp中還有
void wait(jlong millis, bool interruptable, TRAPS);
void notify(TRAPS);
void notifyAll(TRAPS);等方法。
總結
上面介紹的就是HotSpot虛擬機器中Moniter的的加鎖以及解鎖的原理。
通過這篇文章我們知道了sychronized加鎖的時候，會呼叫objectMonitor的enter方法，解鎖的時候會呼叫exit方法。事實上，只有在JDK1.6之前，synchronized的實現才會直接呼叫ObjectMonitor的enter和exit，這種鎖被稱之為重量級鎖。為什麼說這種方式操作鎖很重呢？
- Java的執行緒是對映到作業系統原生執行緒之上的，如果要阻塞或喚醒一個執行緒就需要作業系統的幫忙，這就要從使用者態轉換到核心態，因此狀態轉換需要花費很多的處理器時間，對於程式碼簡單的同步塊（如被
synchronized修飾的get或set方法）狀態轉換消耗的時間有可能比使用者程式碼執行的時間還要長，所以說synchronized是java語言中一個重量級的操縱。
所以，在JDK1.6中出現對鎖進行了很多的優化，進而出現輕量級鎖，偏向鎖，鎖消除，適應性自旋鎖，鎖粗化(自旋鎖在1.4就有 只不過預設的是關閉的，jdk1.6是預設開啟的)，這些操作都是為了線上程之間更高效的共享資料 ，解決競爭問題。後面的文章會繼續介紹這幾種鎖以及他們之間的關係。