摘要：第三天，太監(jiān)傳話欽天監(jiān)求見一日無事。第四天，欽天監(jiān)一日無事。然后所有的競爭線程放棄自旋，逐個插入到對象里的一個隊列尾部，進入阻塞狀態(tài)。

微信公眾號：IT一刻鐘
大型現(xiàn)實非嚴肅主義現(xiàn)場
一刻鐘與你分享優(yōu)質(zhì)技術(shù)架構(gòu)與見聞，做一個有劇情的程序員
關(guān)注可第一時間了解更多精彩內(nèi)容，定期有福利相送喲。

蜀國有一個皇帝叫蜀道難，他比較難伺候，別的皇帝早朝都是在大殿上同時接見所有大臣，共商國是。他不一樣，他說早朝你們不要有事沒事都跑過來嘰嘰喳喳，有事則來，無事則該干啥干啥去，然后安排太監(jiān)每天早上在大門口守著，每次只允許一個大臣進來匯報情況。
“你敢多放進來一個就砍腦袋的干活。“
太監(jiān)趕緊下跪，說“謫！“。
第一天，太監(jiān)傳話欽天監(jiān)求見，皇帝允了，欽天監(jiān)上殿報曰：”臣稟報，昨日我司夜觀星象，西方忽現(xiàn)王星忽明忽暗，恐戎狄那邊有亂。“
“朕知道了，退下吧”。一日無事。
第二天，太監(jiān)傳話欽天監(jiān)求見，皇帝允了。一日無事。
第三天，太監(jiān)傳話欽天監(jiān)求見......一日無事。
第四天，欽天監(jiān)......一日無事。
第五天，皇帝不耐煩了，和賈太監(jiān)說，欽天監(jiān)這老家伙整天是不是閑著沒事，以后他來了不用給我稟報，直接放他上殿講，講完讓他走吧。
國泰民安的日子依舊過著，每天只有欽天監(jiān)一個人來報告，賈太監(jiān)每次看到是欽天監(jiān)來了，也懶得搭理了，直接放他進去了。（這就是偏向鎖，稍后我細細道來）
又一日，欽天監(jiān)如往常進殿報道，賈太監(jiān)站在門口打著盹，忽然耳邊傳來一個聲音：
“賈太監(jiān)，幫我稟告圣上，工部李尚書求見。”
“emmm...進去吧...嗯？等等，尚書大人你先等等，欽天監(jiān)在里面，你等會再來求見吧。”太監(jiān)一陣后怕，尋思著欽天監(jiān)還在里面呢，這要是放進去了，我這腦袋可就沒了，果然嗜睡誤事。
過了一會兒，李尚書回來詢問求見，被告知欽天監(jiān)還沒走，只好又離去。
又過了一會兒，李尚書又回來詢問求見，正巧欽天監(jiān)走了，太監(jiān)進殿傳話說工部李尚書求見，皇帝宣覲見，李尚書進殿上報了一番東南連連大雨，已派人去監(jiān)察水利，修繕河堤。（這就是輕量級鎖）
忽一日，西戎狄和北匈奴同時對帝國西方和北方發(fā)難，前線戰(zhàn)事消息如片片雪花紛紛涌入京城，瞬間殿外來了一群大臣有要事稟告。
一會兒這個來問賈公公我可以進去了嗎？一會兒那個來問賈公公我可以進去了嗎？
把賈太監(jiān)累的喲，一天下來光說“稍后再來”都把嘴皮子磨破了，沒幾日，賈太監(jiān)就跪在皇帝面前哭泣道：“圣上啊，快想想辦法呀，奴才這身子骨就要交代在門口了。”
皇帝一聽，說你傻啊，叫他們一個個在門外排隊啊，誰叫你要他們稍后來求見的。
賈太監(jiān)細思大喜，覺得有理，次日在門口豎起一個牌子“稟報要事者，這邊排隊”，賈太監(jiān)再也不用一個人對著一群人反復(fù)回話，只需要每次出來一個，然后傳話放進去一個，就可以了。（這就是重量級鎖）
上面這個故事，分別講述了synchronized內(nèi)部四種級別的狀態(tài)，分別是：無鎖狀態(tài)，偏向鎖狀態(tài)，輕量級鎖狀態(tài)，重量級鎖狀態(tài)。

我們首先從重量級鎖開始講，重量級鎖是通過互斥量（Mutex）來實現(xiàn)的，即一個線程進入了synchronized同步塊，在未完成任務(wù)時，會阻塞后面的所有線程。
就像上面的故事所講的，要稟告要事的大臣只能在大殿門口外一個接一個的阻塞排隊。
之所以稱它為重量級鎖，是因為Java線程是映射到操作系統(tǒng)的原生線程上的，如果要阻塞或喚醒一個線程，都需要依靠操作系統(tǒng)從當前用戶態(tài)轉(zhuǎn)換到核心態(tài)中，這種狀態(tài)轉(zhuǎn)換需要耗費處理器很多時間，對于簡單同步塊，可能狀態(tài)轉(zhuǎn)換時間比用戶代碼執(zhí)行時間還要長，導(dǎo)致實際業(yè)務(wù)處理所占比偏小，性能損失較大。
當然這個在虛擬機層面進行了一些比如自旋等待，鎖粗化等等的優(yōu)化，避免陷入頻繁的切換狀態(tài)。在這里我就不細講了，有興趣的可以關(guān)注我，我后續(xù)再和各位看官講上一講。

輕量級鎖是JDK6引入的，它的輕量是相較于通過系統(tǒng)互斥量實現(xiàn)的傳統(tǒng)鎖，輕量鎖并不是用來取代重量級鎖的，而是在沒有大量線程競爭的情況下，減少系統(tǒng)互斥量的使用，降低性能的損耗。
輕量級鎖是通過CAS（Compare And Swap）機制實現(xiàn)的，即如果鎖被其他線程所占用，當前線程會通過自旋來獲取鎖，從而避免用戶態(tài)與核心態(tài)的轉(zhuǎn)換。
就像上面故事所說的，大殿中欽天監(jiān)在匯報工作，工部尚書要求見，并不需要賈太監(jiān)每次都進去問一下皇帝，惹得皇帝龍顏大怒，而是大臣自己隔一段時間便來詢問賈太監(jiān)能不能進去，不能就稍后再來問，直到可以進去為止。

偏向鎖也是JDK6引入的，它存在的依據(jù)是“大多數(shù)情況下，鎖不僅不存在多線程競爭，而且總是由同一線程多次獲得”。它是通過記錄第一次進入同步塊的線程id來實現(xiàn)的，如果下一個要進入同步塊的線程與記錄的線程id相同，則說明這個鎖由此線程占有，可以直接進入到同步塊，不用執(zhí)行CAS。
就像故事中的，如果每天只有欽天監(jiān)一個人來的話，就不用賈太監(jiān)稟告了，賈太監(jiān)每次一看到欽天監(jiān)，尋思著，喲，欽天監(jiān)呢，您自個兒直接進去吧，說完自個兒出來吧。
如果說輕量鎖是為了消除系統(tǒng)互斥量帶來的性能損耗，那么偏向鎖就是為了消除CAS帶來的性能損耗，使之在無競爭的情況下消除整個同步，性能無限接近非同步。

要說這個問題，我們需要先講一下Java對象頭，每個對象都會有一個對象頭，它分為三個部分：

從表格可見，synchronized鎖的信息是存在對象頭里一個叫Mark Word的區(qū)域里的，考慮到虛擬機的空間效率，Mark Word被設(shè)計成非固定的數(shù)據(jù)結(jié)構(gòu)，會根據(jù)對象的狀態(tài)復(fù)用存儲空間來存儲不同的內(nèi)容：

當JVM啟用了偏向鎖模式（JDK6以上默認開啟），新創(chuàng)建對象的Mark Word是未鎖定，未偏向但可偏向狀態(tài)，此時Mark Word中的Thread id為0，表示未偏向任何線程，也叫做匿名偏向(anonymously biased)。

偏向鎖狀態(tài)--->無鎖不可偏向狀態(tài)/輕量級鎖狀態(tài)

當?shù)谝粋€線程嘗試進入同步塊時，發(fā)現(xiàn)Mark Word中線程ID為0，則會使用CAS將自己的線程ID設(shè)置到Mark Word中，并且，在當前線程棧中由高到低順序找到可用的Lock Record，將線程ID記錄下。完成這些，此線程就獲取了鎖對象的偏向鎖。
當該偏向線程再次進入同步塊時，發(fā)現(xiàn)鎖對象偏向的就是當前線程，會往當前線程的棧中添加一條Displaced Mark Word為空的Lock Record中，用來統(tǒng)計重入的次數(shù)，然后繼續(xù)執(zhí)行同步塊代碼，因為線程棧是私有的，不需要CAS指令進行操作，所以在偏向鎖模式下，同一個線程，只會執(zhí)行一個CAS，之后獲取釋放鎖只需要對Lock Record做操作，性能損耗基本可以忽略。
當另外一個線程試圖進入同步塊時，發(fā)現(xiàn)Mark Word中線程ID與自己不相符，這個時候就會引發(fā)偏向鎖的撤銷，變成無鎖不可偏向狀態(tài)或輕量級鎖狀態(tài)，當然，這只是宏觀上的描述，嚴格意義上講是不準確的，因為里面還存在重偏向機制，這里就不過于深入，在后續(xù)的文章中，我會專門出一篇文章，給各位看官詳細介紹偏向鎖到底是怎么回事。

無鎖不可偏向狀態(tài)--->輕量級鎖狀態(tài)

當鎖對象變成無鎖不可偏向狀態(tài)時，多個線程運行到同步塊以后，會檢查鎖對象狀態(tài)值標志是否加鎖，如果沒有鎖，就把鎖對象的Mark Word信息拷貝存儲到當前線程棧楨中Lock Record里，然后通過CAS嘗試把對象的Mark Word的值改變成一個指向自己線程的指針。如果成功，則當前線程獲得鎖對象的輕量級鎖，其他線程的CAS就會失敗，因為鎖對象的Mark Word已經(jīng)變成一個新的指針了，必須等待線程釋放鎖，此時其他線程則通過自旋來競爭鎖。當獲取鎖的線程執(zhí)行完畢釋放鎖的時候，會將Lock Record里面之前拷貝的值還原到鎖對象的Mark Word中。

輕量級鎖狀態(tài)--->重量級鎖狀態(tài)

當自旋次數(shù)超過JVM預(yù)期上限，會影響性能，所以競爭的線程就會把鎖對象的Mark Word指向重鎖，所謂的重鎖，實際上就是一個堆上的monitor對象，即，重量級鎖的狀態(tài)下，對象的Mark Word為指向一個堆中monitor對象的指針。
然后所有的競爭線程放棄自旋，逐個插入到monitor對象里的一個隊列尾部，進入阻塞狀態(tài)。
當成功獲取輕量級鎖的線程執(zhí)行完畢，嘗試通過CAS釋放鎖時，因為Mark Word已經(jīng)指向重鎖，導(dǎo)致輕量級鎖釋放失敗，這時線程就會知道鎖已經(jīng)升級為重量級鎖， 它不僅要釋放當前鎖，還要喚醒其他阻塞的線程來重新競爭鎖。
大概流程如下圖所示：

這里有一點需注意的是：鎖只能升級，不能降級。

synchronized無非以下兩種：
1.對象鎖：修飾非靜態(tài)方法，修飾代碼塊
2.類鎖：修飾靜態(tài)方法，修飾代碼塊
其中按照修飾類型來分，又可以分為代碼塊同步和方法同步

代碼塊同步鎖的是對象，使用monitorenter和monitorexit指令實現(xiàn)的。雖然我知道多一行代碼少一位看官的定理，但是這里還是必須貼一張代碼圖，來證明我沒有瞎說，是有理有據(jù)的“理據(jù)服”。
想要降服妖怪，就得先將其打回原形，所以我們先對一段簡單的代碼進行反編譯，得到它的字節(jié)碼。

    final Object lock = new Object();
    public int subtr(int i){
        synchronized (lock){
            return i-1;
        }
    }

字節(jié)碼：

可以看出，monitorenter指令是在編譯后插入到同步代碼塊的開始位置，monitorexit插入到同步代碼塊結(jié)束的地方，正常情況下monitorenter和monitorexit是一對一的匹配，而后面又出現(xiàn)了一個monitorexit，是因為那里是異常處，用來保證方法執(zhí)行異常的時候，可以自動解鎖，而不會造成死鎖。

方法同步的實現(xiàn)官方?jīng)]有透露，我們嘗試對一個方法同步的代碼進行反編譯。

    public synchronized int add(int i){
        return i+1;
    }

字節(jié)碼：

從字節(jié)碼里也看不到monitorenter和monitorexit，智能發(fā)現(xiàn)flags那里，多了一個ACC_SYNCHRONIZED的標示，沒什么頭緒。不過我猜想，底層應(yīng)該是鎖方法所屬的對象或類。

這就是synchronized的大致原理，打回原形之后來看，是不是就覺得也不過如此？有什么疑問或更好的解讀，可以在下方留言，我們進行愉快友好的磋商交流。
如果覺得有用，記得分享～