深入理解多線程（四）—— Moniter的實(shí)現(xiàn)原理

原文轉(zhuǎn)載：http://www.hollischuang.com/archives/2030

在深入理解多線程（一）——Synchronized的實(shí)現(xiàn)原理中介紹過關(guān)于Synchronize的實(shí)現(xiàn)原理，無(wú)論是同步方法還是同步代碼塊，無(wú)論是ACC_SYNCHRONIZED還是monitorenter、monitorexit都是基于Monitor實(shí)現(xiàn)的，那么這篇來介紹下什么是Monitor。

操作系統(tǒng)中的管程

如果你在大學(xué)學(xué)習(xí)過操作系統(tǒng)，你可能還記得管程（monitors）在操作系統(tǒng)中是很重要的概念。同樣Monitor在java同步機(jī)制中也有使用。

管程 (英語(yǔ)：Monitors，也稱為監(jiān)視器) 是一種程序結(jié)構(gòu)，結(jié)構(gòu)內(nèi)的多個(gè)子程序（對(duì)象或模塊）形成的多個(gè)工作線程互斥訪問共享資源。這些共享資源一般是硬件設(shè)備或一群變量。管程實(shí)現(xiàn)了在一個(gè)時(shí)間點(diǎn)，最多只有一個(gè)線程在執(zhí)行管程的某個(gè)子程序。與那些通過修改數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)互斥訪問的并發(fā)程序設(shè)計(jì)相比，管程實(shí)現(xiàn)很大程度上簡(jiǎn)化了程序設(shè)計(jì)。 管程提供了一種機(jī)制，線程可以臨時(shí)放棄互斥訪問，等待某些條件得到滿足后，重新獲得執(zhí)行權(quán)恢復(fù)它的互斥訪問。

Java線程同步相關(guān)的Moniter

在多線程訪問共享資源的時(shí)候，經(jīng)常會(huì)帶來可見性和原子性的安全問題。為了解決這類線程安全的問題，Java提供了同步機(jī)制、互斥鎖機(jī)制，這個(gè)機(jī)制保證了在同一時(shí)刻只有一個(gè)線程能訪問共享資源。這個(gè)機(jī)制的保障來源于監(jiān)視鎖Monitor，每個(gè)對(duì)象都擁有自己的監(jiān)視鎖Monitor。

先來舉個(gè)例子，然后我們?cè)谏显创a。我們可以把監(jiān)視器理解為包含一個(gè)特殊的房間的建筑物，這個(gè)特殊房間同一時(shí)刻只能有一個(gè)客人（線程）。這個(gè)房間中包含了一些數(shù)據(jù)和代碼。

如果一個(gè)顧客想要進(jìn)入這個(gè)特殊的房間，他首先需要在走廊（Entry Set）排隊(duì)等待。調(diào)度器將基于某個(gè)標(biāo)準(zhǔn)（比如 FIFO）來選擇排隊(duì)的客戶進(jìn)入房間。如果，因?yàn)槟承┰?，該客戶客戶暫時(shí)因?yàn)槠渌虑闊o(wú)法脫身（線程被掛起），那么他將被送到另外一間專門用來等待的房間（Wait Set），這個(gè)房間的可以可以在稍后再次進(jìn)入那件特殊的房間。如上面所說，這個(gè)建筑屋中一共有三個(gè)場(chǎng)所。

總之，監(jiān)視器是一個(gè)用來監(jiān)視這些線程進(jìn)入特殊的房間的。他的義務(wù)是保證（同一時(shí)間）只有一個(gè)線程可以訪問被保護(hù)的數(shù)據(jù)和代碼。

Monitor其實(shí)是一種同步工具，也可以說是一種同步機(jī)制，它通常被描述為一個(gè)對(duì)象，主要特點(diǎn)是：

對(duì)象的所有方法都被“互斥”的執(zhí)行。好比一個(gè)Monitor只有一個(gè)運(yùn)行“許可”，任一個(gè)線程進(jìn)入任何一個(gè)方法都需要獲得這個(gè)“許可”，離開時(shí)把許可歸還。

通常提供singal機(jī)制：允許正持有“許可”的線程暫時(shí)放棄“許可”，等待某個(gè)謂詞成真（條件變量），而條件成立后，當(dāng)前進(jìn)程可以“通知”正在等待這個(gè)條件變量的線程，讓他可以重新去獲得運(yùn)行許可。

監(jiān)視器的實(shí)現(xiàn)

在Java虛擬機(jī)(HotSpot)中，Monitor是基于C++實(shí)現(xiàn)的，由ObjectMonitor實(shí)現(xiàn)的，其主要數(shù)據(jù)結(jié)構(gòu)如下：

  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中有幾個(gè)關(guān)鍵屬性：

_owner：指向持有ObjectMonitor對(duì)象的線程

_WaitSet：存放處于wait狀態(tài)的線程隊(duì)列

_EntryList：存放處于等待鎖block狀態(tài)的線程隊(duì)列

_recursions：鎖的重入次數(shù)

_count：用來記錄該線程獲取鎖的次數(shù)

當(dāng)多個(gè)線程同時(shí)訪問一段同步代碼時(shí)，首先會(huì)進(jìn)入_EntryList隊(duì)列中，當(dāng)某個(gè)線程獲取到對(duì)象的monitor后進(jìn)入_Owner區(qū)域并把monitor中的_owner變量設(shè)置為當(dāng)前線程，同時(shí)monitor中的計(jì)數(shù)器_count加1。即獲得對(duì)象鎖。

若持有monitor的線程調(diào)用wait()方法，將釋放當(dāng)前持有的monitor，_owner變量恢復(fù)為null，_count自減1，同時(shí)該線程進(jìn)入_WaitSet集合中等待被喚醒。若當(dāng)前線程執(zhí)行完畢也將釋放monitor(鎖)并復(fù)位變量的值，以便其他線程進(jìn)入獲取monitor(鎖)。如下圖所示

ObjectMonitor類中提供了幾個(gè)方法：

獲得鎖

void ATTR ObjectMonitor::enter(TRAPS) {
  Thread * const Self = THREAD ;
  void * cur ;
  //通過CAS嘗試把monitor的`_owner`字段設(shè)置為當(dāng)前線程
  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 ;
  }
  // 如果舊值和當(dāng)前線程一樣，說明當(dāng)前線程已經(jīng)持有鎖，此次為重入，_recursions自增，并獲得鎖。
  if (cur == Self) { 
     // TODO-FIXME: check for integer overflow!  BUGID 6557169.
     _recursions ++ ;
     return ;
  }

  // 如果當(dāng)前線程是第一次進(jìn)入該monitor，設(shè)置_recursions為1，_owner為當(dāng)前線程
  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 ;
  }

  // 省略部分代碼。
  // 通過自旋執(zhí)行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 ;
   //如果當(dāng)前線程不是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次數(shù)不為0.自減
   if (_recursions != 0) {
     _recursions--;        // this is simple recursive enter
     TEVENT (Inflated exit - recursive) ;
     return ;
   }

   //省略部分代碼，根據(jù)不同的策略（由QMode指定），從cxq或EntryList中獲取頭節(jié)點(diǎn)，通過ObjectMonitor::ExitEpilog方法喚醒該節(jié)點(diǎn)封裝的線程，喚醒操作最終由unpark完成。

除了enter和exit方法以外，objectMonitor.cpp中還有

void      wait(jlong millis, bool interruptable, TRAPS);
void      notify(TRAPS);
void      notifyAll(TRAPS);

等方法。

總結(jié)

上面介紹的就是HotSpot虛擬機(jī)中Moniter的的加鎖以及解鎖的原理。

通過這篇文章我們知道了sychronized加鎖的時(shí)候，會(huì)調(diào)用objectMonitor的enter方法，解鎖的時(shí)候會(huì)調(diào)用exit方法。事實(shí)上，只有在JDK1.6之前，synchronized的實(shí)現(xiàn)才會(huì)直接調(diào)用ObjectMonitor的enter和exit，這種鎖被稱之為重量級(jí)鎖。為什么說這種方式操作鎖很重呢？

  • Java的線程是映射到操作系統(tǒng)原生線程之上的，如果要阻塞或喚醒一個(gè)線程就需要操作系統(tǒng)的幫忙，這就要從用戶態(tài)轉(zhuǎn)換到核心態(tài)，因此狀態(tài)轉(zhuǎn)換需要花費(fèi)很多的處理器時(shí)間，對(duì)于代碼簡(jiǎn)單的同步塊（如被synchronized修飾的get 或set方法）狀態(tài)轉(zhuǎn)換消耗的時(shí)間有可能比用戶代碼執(zhí)行的時(shí)間還要長(zhǎng)，所以說synchronized是java語(yǔ)言中一個(gè)重量級(jí)的操縱。

所以，在JDK1.6中出現(xiàn)對(duì)鎖進(jìn)行了很多的優(yōu)化，進(jìn)而出現(xiàn)輕量級(jí)鎖，偏向鎖，鎖消除，適應(yīng)性自旋鎖，鎖粗化(自旋鎖在1.4就有 只不過默認(rèn)的是關(guān)閉的，jdk1.6是默認(rèn)開啟的)，這些操作都是為了在線程之間更高效的共享數(shù)據(jù) ，解決競(jìng)爭(zhēng)問題。后面的文章會(huì)繼續(xù)介紹這幾種鎖以及他們之間的關(guān)系。

Java Synchronized實(shí)現(xiàn)原理

JVM源碼分析之Object.wait/notify實(shí)現(xiàn)

Linux Kernel CMPXCHG函數(shù)分析

從jvm源碼看synchronized

（全文完）

下一篇：深入理解多線程（五）—— Java虛擬機(jī)的鎖優(yōu)化技術(shù)

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容