前言
前兩篇文章，我們聊了聊線程/進程的概念，接着簡單串了一下同步的方式方法。今天我們就單拎出來synchronized，好好捋一捋它的前世今生。
正文
小A：咱們前幾天鋪墊了這麼多內容，今天是不是要好好的深挖一下原理的內容了？
MDove：沒錯，接下來。我會從常見的synchronized加鎖方式入手；引出Java對象在內存的佈局，以及鎖的存放位置；然後看一看鎖在C++中的簡單實現思路；最後咱們從字節碼中，看一下JVM如果識別synchronized。內容不是很難，不會涉及到特別多深奧的內容，大部分是平鋪直敘的介紹，很適合閱讀呦~
小A：快點開始吧，我等不及啦。
淺聊synchronized的使用
MDove：說起synchronized的底層實現原來，咱們先看看synchronized的倆種加鎖方式：
1、某個對象實例內
此作用域內的synchronized鎖 ，可以防止多個線程同時訪問這個對象的synchronized方法
並且一個對象有多個synchronized方法，只要一個線程訪問了其中的一個synchronized方法，其它線程不能同時訪問這個對象中任何一個synchronized方法。
此外，不同對象實例的synchronized方法是不相干預的。也就是說，其它線程可以同時訪問此類下的另一個對象實例中的synchronized方法；
2、某個類
此作用域下，可以防止多個線程同時訪問這個類中的synchronized方法。也就是說此種修飾，可以對此類的所有對象實例起作用。
MDove：注意一點，synchronized關鍵字是不能繼承的，也就是說，基類的方法synchronized fun(){} 在繼承類中並不自動是synchronized fun(){}，而是變成了fun(){}。繼承時，需要顯式的指定它的某個方法爲synchronized方法。有機會你可以自己寫個demo試一下。
常見錯誤
MDove：你來看一看下面這個demo，有沒有什麼問題？
小A：沒覺得有問題吶？這不就是第一種加鎖的方式，鎖實例對象麼？
MDove：既然你都知道是鎖實例對象，那你沒看出來問題麼？雖然我們使用synchronized修飾了add()。但是卻new了兩個不同的實例對象，這也就意味着存在着兩個不同的實例對象鎖，因此t1和t2都會進入各自的對象鎖，也就是說t1和t2線程使用的是不同的鎖，因此線程安全是無法保證的。
小A：對對對，沒錯。那解決這種問題，是不是需要用第二種加鎖的方式，鎖住這個類？
MDove：沒錯，解決這種困境的的方式是將synchronized作用於靜態的add方法，這樣的話，對象鎖就當前類，因爲類對象只有一個，因此無論new多少個實例對象都是安全的：
小A：那是不是這樣改寫就可以了？
MDove：沒錯就是這樣，很簡單。接下來讓我們看一些深入的內容，鎖的實現。
synchronized鎖的底層實現
MDove：我們都知道，對象被創建在堆中。並且對象在內存中的存儲佈局方式可以分爲3塊區域：對象頭、實例數據、對齊填充。其中對象頭，便是我們今天的主角。
關於實例數據、對齊填充的作用，各位小夥伴可以參考《深入理解Java虛擬機》。
MDove：對於對象頭來說，主要是包括倆部分信息：
1、自身運行時的數據，比如：鎖狀態標誌、線程持有的鎖…等等。（此部分內容被稱之爲Mark Word）
今天我們只聊：指向重量級鎖的指針
2、另一部分是類型指針：JVM通過這個指針來確定這個對象是哪個類的實例。
MDove：今天我們主要聊的是對象頭，第一部分中重量級鎖的內容。
MDove：先讓我們從宏觀的角度看一看synchronized鎖的實現原理。
synchronized鎖的宏觀實現
MDove：synchronized的對象鎖，其指針指向的是一個monitor對象（由C++實現）的起始地址。每個對象實例都會有一個 monitor。其中monitor可以與對象一起創建、銷燬；亦或者當線程試圖獲取對象鎖時自動生成。
monitor是由ObjectMonitor實現（ObjectMonitor.hpp文件，C++實現的），對於我們來說主要關注的是如下代碼：
MDove：我們可以看到這裏定義了_WaitSet 和 _EntryList倆個隊列，其中_WaitSet 用來保存每個等待鎖的線程對象。
小A：那_EntryList呢？
MDove：彆着急，讓我們先看一下_owner，它指向持有ObjectMonitor對象的線程。當多個線程同時訪問一段同步代碼時，會先存放到 _EntryList 集合中，接下來當線程獲取到對象的monitor時，就會把_owner變量設置爲當前線程。同時count變量+1。如果線程調用wait() 方法，就會釋放當前持有的monitor，那麼_owner變量就會被置爲null，同時_count減1，並且該線程進入 WaitSet集合中，等待下一次被喚醒。
MDove：當然，若當前線程順利執行完方法，也將釋放monitor，重走一遍剛纔的內容，也就是_owner變量就會被置爲null，同時_count減1，並且該線程進入 WaitSet集合中，等待下一次被喚醒。
因爲這個鎖對象存放在對象本身，也就是爲什麼Java中任意對象可以作爲鎖的原因。
synchronized代碼塊的底層實現
MDove：咱們先寫一個簡單的demo，然後看一下它們的字節碼：
MDove：根據虛擬機規範要求，在執行monitorenter指令時，首先要嘗試獲取對象鎖，也就是上文我們提到了monitor對象。如果這個對象沒有被鎖定，或者當前線程已經擁有了這個對象的鎖，那麼就把鎖的計數器（_count）加1。當然與之對應執行monitorexit指令時，鎖的計數器（_count）也會減1。
MDove：如果當前線程獲取鎖失敗，那麼就會被阻塞住，進入_WaitSet 中，等待鎖被釋放爲止。
小A：等等，我看到字節碼中，有倆個monitorexit指令，這是爲什麼呢？
MDove：是這樣的，編譯器需要確保方法中調用過的每條monitorenter指令都要執行對應的monitorexit 指令。爲了保證在方法異常時，monitorenter和monitorexit指令也能正常配對執行，編譯器會自動產生一個異常處理器，它的目的就是用來執行 異常的monitorexit指令。而字節碼中多出的monitorexit指令，就是異常結束時，被執行用來釋放monitor的。
小A：我們剛纔看的是同步代碼塊的原理，那麼直接修飾在方法上呢？也是通過這個倆個指令嗎？
MDove：你別說，還真不是：
MDove：可以看到：字節碼中並沒有monitorenter指令和monitorexit指令，取得代之的是ACC_SYNCHRONIZED標識，JVM通過ACC_SYNCHRONIZED標識，就可以知道這是一個需要同步的方法，進而執行上述同步的過程，也就是_count加1，這些過程。
小A：哦，原來是這樣。一個是用了指令，一個是用的標識呀~對了，我聽說synchronized的性能特別低是這樣麼？
MDove：這句話不全對，JDK1.5後對synchronized進行了大刀闊斧的優化，這其中涉及到偏向鎖、輕量級鎖、自旋鎖、鎖消除等手段。時候也不早了，這些內容今天就不展開了。有機會我們下次再學習吧~