原文轉載：http://www.hollischuang.com/archives/2030
在深入理解多線程（一）——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是默認開啟的)，這些操作都是為了在線程之間更高效的共享數據 ，解決競爭問題。后面的文章會繼續介紹這幾種鎖以及他們之間的關系。
（全文完）
