Java版管程：Synchronized
一、同步機制
保證共享資源的讀寫安全，需要一種同步機制：用于解決 2 方面問題：
- 線程間通信：線程間交換信息的機制
- 線程間同步：控制不同線程之間操作發(fā)生相對順序的機制
二、同步機制-管程
2.1 認識管程
同步機制中有經(jīng)典的管程方案，關(guān)于管程在在中國大學(xué) mooc 中搜索 管程 有些大學(xué)的操作系統(tǒng)課程會講解管程。管程其實就是對共享變量以及其操作的封裝：
- 將共享資源封裝起來，對外提供操作這些共享資源的方法。
- 線程只能通過調(diào)用管程中的方法來間接地訪問管程中的共享資源
2.2 管程如何解決同步和通信問題
1）同步問題
- 管程是互斥進入，提供了入口等待隊列，用于存儲等待進入同步代碼塊的線程
- 管程的互斥進入是由編譯器負責(zé)保證的，
通常的做法是用一個互斥量或二元信號量
2）通信問題，管程中設(shè)置條件變量，提供等待/喚醒操作
- 條件變量 ：java 里理解為鎖對象自身
- 等待操作 ：等待條件變量時，將線程存儲到條件變量的等待隊列中，此時，應(yīng)先釋放管程的使用權(quán)，不然其它線程拿不到使用權(quán)
- 喚醒操作 ：通過發(fā)送信號將等待隊列中的線程喚醒
2.3 關(guān)鍵數(shù)據(jù)結(jié)構(gòu)和方法
1）等待隊列
- 入口等待隊列：存儲等待進入同步代碼塊的線程；線程進入管程后，可以執(zhí)行同步塊代碼。在 java 中是 _EntryList
- 條件等待隊列：入口等待隊列中的線程，進入管程后，執(zhí)行同步塊代碼的過程中，需要等待某個條件滿足之后，才能繼續(xù)執(zhí)行，就將線程放入此變量的等待隊列中。MESA管程中是多個條件等待隊列，java 是面向?qū)ο蟮脑O(shè)計，這里的條件變量即鎖對象自身（線程都在等待擁有這個鎖），所以只有一個條件變量等待隊列即_WaitSet 。
2）同步方法
- wait() ：等待條件變量，將當(dāng)前線程放入條件變量的等待隊列中
- notify()：激活某個條件變量上等待隊列中的一個線程
- notifyAll()：激活某個條件變量上等待隊列中的所有線程
三、Java 版的管程 synchronized
synchronized 是語法糖，會被編譯器編譯成：1 個 monitorenter 和 2 個 moitorexit（一個用于正常退出，一個用于異常退出）。monitorenter 和 正常退出的 monitorexit 中間是 synchronized 包裹的代碼，如下圖：
image.png
在 HotSpot 虛擬機中，monitor 是由 ObjectMonitor 實現(xiàn)的，ObjectMonitor 主要數(shù)據(jù)結(jié)構(gòu)如下：
- _count：記錄 owner 線程獲取鎖的次數(shù)，即重入次數(shù)，也即是可重入的。
- _owner：指向擁有該對象的線程
- _EntryList：管程的入口等待隊列，即存放等待鎖而被 block 的線程。
- _WaitSet：管程的條件變量等待隊列，存放的是擁有鎖后又調(diào)用了 wait()方法的線程；
進入 _EntryList 的線程需要與其他線程爭搶鎖，搶到鎖之后以排它方式執(zhí)行同步代碼塊的代碼，當(dāng)其再調(diào)用wait()方法后進入_WaitSet，當(dāng)_WaitSet里的線程被 notify()/notifyAll() 后，將從 _WaitSet 中移動到 _EntryList 中。
四、使用鎖
4.1 對實例對象加鎖
- 同步實例方法
public synchronized void fun(){
}- 同步代碼塊 參數(shù)是實例
public void fun(){
synchronized(this){
...
}
}4.2 對類加鎖
- 同步靜態(tài)方法
class Aclass{
static synchronized void fun(){
}
}- 同步代碼塊 參數(shù)是類
class Aclass{
static void fun(){
synchronized (Aclass.class){
}
}
}4.3 對象的內(nèi)存結(jié)構(gòu)
HotSpot 虛擬機中，對象在內(nèi)存中存儲的布局可以分為三塊區(qū)域:對象頭 (Header)、實例數(shù)據(jù)(Instance Data)和對齊填充(Padding)。
其中對象頭中的 Mark Word 區(qū)域中會存儲 對象鎖，鎖狀態(tài)標(biāo)志，偏向 鎖(線程)ID，偏向時間，數(shù)組長度(數(shù)組對象)等，Mark Word 被設(shè)計成一個非固定的數(shù)據(jù)結(jié)構(gòu)以便在極小的空間內(nèi) 存存儲盡量多的數(shù)據(jù)，它會根據(jù)對象的狀態(tài)復(fù)用自己的存儲空間，也就是說， Mark Word 會隨著程序的運行發(fā)生變化，32 位虛擬機中變化狀態(tài)如下：
五、鎖的變化
鎖的性能開銷的變化：無鎖——>偏向鎖——>輕量級鎖——>重量級鎖，并且膨脹方向不可逆。
偏向鎖：線程獲取鎖后，鎖對象的 Mark Word 標(biāo)記偏向鎖，通過一個字段記錄當(dāng)前線程 id，邏輯如下：
- 本線程再次爭取鎖時：檢查到這個線程 ID 跟自己一樣就重入
- 不同的線程爭取鎖：鎖對象中的線程 ID 不是自己，且有偏向鎖標(biāo)識，則發(fā)起偏向鎖取消操作，
偏向鎖的撤銷需要等待全局安全點
- 若偏向鎖取消成功，且之后當(dāng)前線程又通過 CAS 操作爭取到了鎖，則繼續(xù)保持偏向鎖狀態(tài)
- 若經(jīng)過一次 CAS 操作未爭取到鎖，意味著還有其他的線程也在競爭這個鎖，此時就進行鎖升級，升級為輕量級鎖
- 輕量級鎖是自適應(yīng)自旋鎖
- 自旋獲取鎖成功，是保持輕量級鎖狀態(tài)嗎？？
- 自旋獲取鎖失敗 ，則進入重量級鎖
5.1 成本的差異
不同的鎖性能成本不同：
1）重量級鎖：線程在用戶態(tài)到內(nèi)核態(tài)之間切換成本高
鎖不能降級，鎖變成重量級鎖之后，就一直要作為重量級鎖使用嗎？那還怎么自適應(yīng)自旋？？
Java 鎖優(yōu)化--JVM 鎖降級里說道：鎖降級確實 是會發(fā)生的，當(dāng) JVM 進入安全點（SafePoint）的時候，會檢查是否有閑置的 Monitor，然后試圖進行降級。
2）其他的鎖都是為了更小的開銷
- 偏向鎖：一次 CAS 操作，修改一下鎖中的字段，就被標(biāo)識為拿得到了鎖
- 輕量鎖：一次 CAS 操作拿不到鎖，那就自旋空轉(zhuǎn)多次 CAS 操作，會稍稍費一點 CPU，但是能更快的拿到鎖；自適應(yīng)自旋后，還拿不到鎖，那就只能使用重量級鎖了。
- 自旋鎖：許多情況下，共享數(shù)據(jù)的鎖定狀態(tài)持續(xù)時間較短，切換線程不值得，通過讓線程執(zhí)行循環(huán)等待鎖的釋放，不讓出 CPU。如果得到鎖，就順利進入臨界區(qū)。如果還不能獲得鎖，那就會將線程在操作系統(tǒng)層面掛起，這就是自旋鎖的優(yōu)化方式。但是它也存在缺點：如果鎖被其他線程長時間占用，一直不釋放 CPU，會帶來許多的性能開銷。
- 自適應(yīng)自旋鎖：這種相當(dāng)于是對上面自旋鎖優(yōu)化方式的進一步優(yōu)化，它的自旋的次數(shù)不再固定，其自旋的次數(shù)由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態(tài)來決定，這就解決了自旋鎖帶來的缺點。
5.2 鎖消除
消除鎖是虛擬機另外一種鎖的優(yōu)化，這種優(yōu)化更徹底，在 JIT 編譯時，對運行上下文進行掃描，做逃逸分析，去除不可能存在競爭的鎖（去掉了申請和釋放鎖的代碼了）。比如下面代碼的 method1 和 method2 的執(zhí)行效率是一樣的，因為 object 鎖是私有變量，不存在所得競爭關(guān)系。
鎖消除示例(來自網(wǎng)絡(luò)).png
5.3 鎖粗化
鎖粗化是虛擬機對另一種極端情況的優(yōu)化處理，通過擴大鎖的范圍，避免反復(fù)獲取鎖和釋放鎖。比如下面 method3 經(jīng)過鎖粗化優(yōu)化之后就和 method4 執(zhí)行效率一樣了。
鎖粗化示例(來自網(wǎng)絡(luò)).png
本文轉(zhuǎn)載自微信公眾號「架構(gòu)染色」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系【架構(gòu)染色】公眾號作者。
