一、對(duì)象頭、Mark Word、monitor、synchronized怎么關(guān)聯(lián)起來

（1）首先java里面每個(gè)對(duì)象JVM底層都會(huì)為它創(chuàng)建一個(gè)監(jiān)視器monitor，這個(gè)是JVM層次為我們保證的。這個(gè)監(jiān)視器就類似一個(gè)鎖，哪個(gè)線程持有這個(gè)monitor的操作權(quán)，就相當(dāng)于獲取到了鎖

（2）其次synchronized 修飾的代碼或者方法，底層會(huì)生成兩條指令分別為monitorenter、monitorexit。

（3）進(jìn)入synchronized的代碼塊之前會(huì)執(zhí)行monitorenter指令，去申請(qǐng)monitor監(jiān)視器的操作權(quán)，如果申請(qǐng)成功了，就相當(dāng)于獲取到了鎖。如果已經(jīng)有別的線程申請(qǐng)成功monitor了，這個(gè)時(shí)候它就得等著，等別的線程執(zhí)行完synchronized里面的代碼之后就會(huì)執(zhí)行monitorexit指令釋放monitor監(jiān)視器，這樣其它在等待的線程就可以再次申請(qǐng)獲取monitor監(jiān)視器了。

monitor又是個(gè)啥東西？為什么monitor能當(dāng)做鎖？首先既然你知道每個(gè)對(duì)象都有一個(gè)monitor監(jiān)視器，那你知道每個(gè)對(duì)象是怎么和它的monitor監(jiān)視器關(guān)聯(lián)起來的不？

通過synchronized進(jìn)行加鎖，就是通過對(duì)象頭的Mark Word關(guān)聯(lián)起來的，里面記錄著鎖狀態(tài)和占有鎖的線程地址指針。

當(dāng)Mark Word中最后兩位的鎖標(biāo)志位是10的時(shí)候，Mark Word的前面是monitor監(jiān)視器的地址，我現(xiàn)在就給你畫出來對(duì)象頭、Mark Word 和 monitor之間的關(guān)系圖(32位）：

二、monitor內(nèi)部結(jié)構(gòu)

monitor叫做對(duì)象監(jiān)視器、也叫作監(jiān)視器鎖，JVM規(guī)定了每一個(gè)java對(duì)象都有一個(gè)monitor對(duì)象與之對(duì)應(yīng)，這monitor是JVM幫我們創(chuàng)建的，在底層使用C++實(shí)現(xiàn)的。

其實(shí)monitor在C++底層也是某個(gè)類的對(duì)象，那個(gè)類就是ObjectMonitor，它擁有的屬性也字段如下：

//結(jié)構(gòu)體如下
ObjectMonitor::ObjectMonitor() {
_header;
_count ;  // 非常重要，表示鎖計(jì)數(shù)器，_count = 0表示還沒人加鎖，_count > 0 表示加鎖的次數(shù)
_waiters;
_recursions;
_owner; // 非常重要，指向加鎖成功的線程，_owner = null 時(shí)候表示沒人加鎖
_waitset;  // wait線程的集合，在synchorized代碼塊中調(diào)用wait()方法的線程會(huì)被加入到此集合中沉睡，等待別人叫醒它
_waitsetLock;
_responsiable;
_succ;
_cxq;
_freenext;
_entrylist;  // 非常重要，等待隊(duì)列，加鎖失敗的線程會(huì)被加入到這個(gè)等待隊(duì)列中，等待再次爭(zhēng)搶鎖
_spinFreq;  // 獲取鎖之前的自旋的次數(shù)
_spinclock; // 獲取之前每次鎖自旋的時(shí)間
ownerIsThread;
}

3.1、monitor加鎖原理

_count : 這個(gè)屬性非常重要，直接表示有沒有被加鎖，如果沒被線程加鎖則 _count=0，如果_count大于0則說明被加鎖了

_owner：這個(gè)屬性也非常重要，直接指向加鎖的線程，比如線程A獲取鎖成功了，則_owner = 線程A；當(dāng)_owner = null的時(shí)候表示沒線程加鎖

_waitset：當(dāng)持有鎖的線程調(diào)用wait()方法的時(shí)候，那個(gè)線程就會(huì)釋放鎖，然后線程被加入到monitor的waitset集合中等待，然后線程就會(huì)被掛起。只有有別的線程調(diào)用notify將它喚醒。_entrylist：這個(gè)就是等待隊(duì)列，當(dāng)線程加鎖失敗的時(shí)候被block住，然后線程會(huì)被加入到這個(gè)entrylist隊(duì)列中，等待獲取鎖。

_spinFreq：獲取鎖失敗前自旋的次數(shù)；JDK1.6之后對(duì)synchronized進(jìn)行優(yōu)化；原先JDK1.6以前，只要線程獲取鎖失敗，線程立馬被掛起，線程醒來的時(shí)候再去競(jìng)爭(zhēng)鎖，這樣會(huì)導(dǎo)致頻繁的上下文切換，性能太差了。JDK1.6后優(yōu)化了這個(gè)問題，就是線程獲取鎖失敗之后，不會(huì)被立馬掛起，而是每個(gè)一段時(shí)間都會(huì)重試去爭(zhēng)搶一次，這個(gè)_spinFreq就是最大的重試次數(shù)，也就是自旋的次數(shù)，如果超過了這個(gè)次數(shù)搶不到，那線程只能沉睡了。_spinClock：上面說獲取鎖失敗每隔一段時(shí)間都會(huì)重試一次，這個(gè)屬性就是自旋間隔的時(shí)間周期，比如50ms，那么就是每隔50ms就嘗試一次獲取鎖。

下面通過圖文展示加鎖過程：

（1）首先呢，沒有線程對(duì)monitor進(jìn)行加鎖的時(shí)候是這樣的：

說明：_count = 0 表示加鎖次數(shù)是0，也就是沒線程加鎖；_owner 指向null，也就是沒線程加鎖

（2）然后呢，這個(gè)時(shí)候線程A、線程B來競(jìng)爭(zhēng)加鎖了，如下圖所示：

（3）線程A競(jìng)爭(zhēng)到鎖，將_count 修改為1，表示加鎖次數(shù)為1，將_owner = 線程A，也就是指向自己，表示線程A獲取到了鎖。在_count = 0，_owner = null的時(shí)候，表示monitor沒人加鎖，這個(gè)時(shí)候線程A和線程B同時(shí)請(qǐng)求加鎖，也就是競(jìng)爭(zhēng)將_count改為1。由于線程A這哥們動(dòng)作比較快，它將_count改為1，獲取鎖成功了。它還嘚瑟了一下，同時(shí)將_onwer = 線程A，表示自己獲取了鎖，告訴線程B，兄弟不好意思了，是我獲取了鎖，我先去操作了。

既然加鎖就是將_count 設(shè)置為1，同時(shí)將_owner 指向自己。那反過來推測(cè)，釋放鎖的時(shí)候是不是將_count 設(shè)置為 0 , 將 _owner 設(shè)置為 null 就 OK了？是的，釋放鎖的過程就是這么簡(jiǎn)單：

加鎖和釋放鎖說完了，我們接下來將的是

_spinFreq、_spinclock、_entrylist

這幾個(gè)東西：

上面解釋字段屬性的時(shí)候說_spinFreq是等待鎖期間自旋的次數(shù)、_spinclock是自旋的周期也就是每次自旋多久時(shí)間、_entrylist這個(gè)就是自旋次數(shù)用完了還沒獲取鎖，只能放到_entrylist等待隊(duì)列掛起了。

讓我們繼續(xù)接著圖來講：

（1）首先線程B獲取鎖的時(shí)候發(fā)現(xiàn)monitor已經(jīng)被線程A加鎖了（2）然后monitor里面記錄的_spinFreq 、spinclock 信息告訴線程B，你可以每隔50ms來嘗試加鎖一次，總共可以嘗試10次（3）如果線程B在10次嘗試加鎖期間，獲取鎖成功了，那線程B將_count 設(shè)置為 1，_owner 指向自己表示自己獲取鎖成功了（4）如果10次嘗試獲取鎖此時(shí)都用完了，那沒轍了，它只能放到等待隊(duì)列里面先睡覺去了，也就是線程B被掛起了

_spinFreq和_spinclock 這兩個(gè)monitor的屬性主要是讓線程自旋的時(shí)候使用的吧。

entryList作用是當(dāng)線程自旋次數(shù)都用完了之后，只能進(jìn)入等待隊(duì)列進(jìn)行休眠了。

4.6、輕量級(jí)鎖

輕量級(jí)鎖模式下，加鎖之前會(huì)創(chuàng)建一個(gè)鎖記錄，然后將Mark Word中的數(shù)據(jù)備份到鎖記錄中（Mark Word存儲(chǔ)hashcode、GC年齡等很重要數(shù)據(jù)，不能丟失了），以便后續(xù)恢復(fù)Mark Word使用。這個(gè)鎖記錄放在加鎖線程的虛擬機(jī)棧中，加鎖的過程就是將Mark Word 前面的30位指向鎖記錄地址。所以mark word的這個(gè)地址指向哪個(gè)線程的虛擬機(jī)棧中，就說明哪個(gè)線程獲取了輕量級(jí)鎖。就好比下面的圖，線程A獲取了輕量級(jí)鎖，鎖記錄存在線程A的虛擬機(jī)棧中，然后Mark Word的前面30位存儲(chǔ)鎖記錄的地址。

了解了輕量級(jí)加鎖的原理之后，我們繼續(xù)，來講講偏向鎖升級(jí)為輕量級(jí)鎖的過程：

（1）首先線程A持有偏向鎖，然后正在執(zhí)行synchronized塊中的代碼

（2）這個(gè)時(shí)候線程B來競(jìng)爭(zhēng)鎖，發(fā)現(xiàn)有人加了偏向鎖并且正在執(zhí)行synchronized塊中的代碼，為了避免上述說的線程A一直持有鎖不釋放的情況，需要對(duì)鎖進(jìn)行升級(jí)，升級(jí)為輕量級(jí)鎖

（3）先將線程A暫停，為線程A創(chuàng)建一個(gè)鎖記錄Lock Record，將Mark Word的數(shù)據(jù)復(fù)制到鎖記錄中；然后將鎖記錄放入線程A的虛擬機(jī)棧中

（4）然后將Mark Word中的前30位指向線程A中鎖記錄的地址，將線程A喚醒，線程A就知道自己持有了輕量級(jí)鎖

4.6.2、在輕量級(jí)鎖模式下，多線程是怎么競(jìng)爭(zhēng)鎖和釋放鎖的？

（1）線程A和線程B同時(shí)競(jìng)爭(zhēng)鎖，在輕量級(jí)鎖模式下，都會(huì)創(chuàng)建Lock Record鎖記錄放入自己的棧幀中

（2）同時(shí)執(zhí)行CAS操作，將Mark Word前30位設(shè)置為自己鎖記錄的地址，誰設(shè)置成功了，鎖就獲取到鎖

上面講了加鎖的過程，輕量級(jí)鎖的釋放很簡(jiǎn)單，就將自己的Lock Record中的Mark Word備份的數(shù)據(jù)恢復(fù)回去即可，恢復(fù)的時(shí)候執(zhí)行的是CAS操作將Mark Word數(shù)據(jù)恢復(fù)成加鎖前的樣子。

Java synchronized偏向鎖后hashcode存在哪里？

jdk8偏向鎖是默認(rèn)開啟，但是是有延時(shí)的，可通過參數(shù)： -XX:BiasedLockingStartupDelay=0關(guān)閉延時(shí)。

hashcode是懶加載，在調(diào)用hashCode方法后才會(huì)保存在對(duì)象頭中。

當(dāng)對(duì)象頭中沒有hashcode時(shí)，對(duì)象頭鎖的狀態(tài)是 可偏向（ biasable，101，且無線程id）。

如果在同步代碼塊之前調(diào)用hashCode方法，則對(duì)象頭中會(huì)有hashcode，且鎖狀態(tài)是 不可偏向（0 01），這時(shí)候再執(zhí)行同步代碼塊，鎖直接是 輕量級(jí)鎖（thin lock，00）。

如果是在同步代碼塊中執(zhí)行hashcode，則鎖是從 偏向鎖 直接膨脹為 重量級(jí)鎖。