Java版管程：Synchronized

作者：石頁兄 2023-06-06 08:47:57

開發前端

synchronized 是語法糖，會被編譯器編譯成：1 個 monitorenter 和 2 個 moitorexit（一個用于正常退出，一個用于異常退出）。

一、同步機制

保證共享資源的讀寫安全，需要一種同步機制：用于解決 2 方面問題：

線程間通信：線程間交換信息的機制
線程間同步：控制不同線程之間操作發生相對順序的機制

二、同步機制-管程

2.1 認識管程

同步機制中有經典的管程方案，關于管程在在中國大學 mooc 中搜索管程有些大學的操作系統課程會講解管程。管程其實就是對共享變量以及其操作的封裝：

將共享資源封裝起來，對外提供操作這些共享資源的方法。
線程只能通過調用管程中的方法來間接地訪問管程中的共享資源

2.2 管程如何解決同步和通信問題

1）同步問題

管程是互斥進入，提供了入口等待隊列，用于存儲等待進入同步代碼塊的線程
管程的互斥進入是由編譯器負責保證的，

通常的做法是用一個互斥量或二元信號量

2）通信問題，管程中設置條件變量，提供等待/喚醒操作

條件變量：java 里理解為鎖對象自身
等待操作：等待條件變量時，將線程存儲到條件變量的等待隊列中，此時，應先釋放管程的使用權，不然其它線程拿不到使用權
喚醒操作：通過發送信號將等待隊列中的線程喚醒

2.3 關鍵數據結構和方法

1）等待隊列

入口等待隊列：存儲等待進入同步代碼塊的線程；線程進入管程后，可以執行同步塊代碼。在 java 中是 _EntryList
條件等待隊列：入口等待隊列中的線程，進入管程后，執行同步塊代碼的過程中，需要等待某個條件滿足之后，才能繼續執行，就將線程放入此變量的等待隊列中。MESA管程中是多個條件等待隊列，java 是面向對象的設計，這里的條件變量即鎖對象自身（線程都在等待擁有這個鎖），所以只有一個條件變量等待隊列即_WaitSet 。

2）同步方法

wait() ：等待條件變量，將當前線程放入條件變量的等待隊列中
notify()：激活某個條件變量上等待隊列中的一個線程
notifyAll()：激活某個條件變量上等待隊列中的所有線程

三、Java 版的管程 synchronized

synchronized 是語法糖，會被編譯器編譯成：1 個 monitorenter 和 2 個 moitorexit（一個用于正常退出，一個用于異常退出）。monitorenter 和正常退出的 monitorexit 中間是 synchronized 包裹的代碼，如下圖：

image.png

在 HotSpot 虛擬機中，monitor 是由 ObjectMonitor 實現的，ObjectMonitor 主要數據結構如下：

_count：記錄 owner 線程獲取鎖的次數，即重入次數，也即是可重入的。
_owner：指向擁有該對象的線程
_EntryList：管程的入口等待隊列，即存放等待鎖而被 block 的線程。
_WaitSet：管程的條件變量等待隊列，存放的是擁有鎖后又調用了 wait()方法的線程；

進入 _EntryList 的線程需要與其他線程爭搶鎖，搶到鎖之后以排它方式執行同步代碼塊的代碼，當其再調用wait()方法后進入_WaitSet，當_WaitSet里的線程被 notify()/notifyAll() 后，將從 _WaitSet 中移動到 _EntryList 中。

四、使用鎖

4.1 對實例對象加鎖

同步實例方法

public synchronized void fun(){
}

同步代碼塊參數是實例

public void fun(){
    synchronized(this){
        ...
    }
}

4.2 對類加鎖

同步靜態方法

class Aclass{
    static synchronized void fun(){
    }
}

同步代碼塊參數是類

class Aclass{
    static void fun(){
        synchronized (Aclass.class){
        }
    }
}

4.3 對象的內存結構

HotSpot 虛擬機中，對象在內存中存儲的布局可以分為三塊區域:對象頭 (Header)、實例數據(Instance Data)和對齊填充(Padding)。

其中對象頭中的 Mark Word 區域中會存儲對象鎖，鎖狀態標志，偏向鎖(線程)ID，偏向時間，數組長度(數組對象)等，Mark Word 被設計成一個非固定的數據結構以便在極小的空間內存存儲盡量多的數據，它會根據對象的狀態復用自己的存儲空間，也就是說， Mark Word 會隨著程序的運行發生變化，32 位虛擬機中變化狀態如下：

五、鎖的變化

鎖的性能開銷的變化：無鎖——>偏向鎖——>輕量級鎖——>重量級鎖，并且膨脹方向不可逆。

偏向鎖：線程獲取鎖后，鎖對象的 Mark Word 標記偏向鎖，通過一個字段記錄當前線程 id，邏輯如下：

本線程再次爭取鎖時：檢查到這個線程 ID 跟自己一樣就重入
不同的線程爭取鎖：鎖對象中的線程 ID 不是自己，且有偏向鎖標識，則發起偏向鎖取消操作，

偏向鎖的撤銷需要等待全局安全點

若偏向鎖取消成功，且之后當前線程又通過 CAS 操作爭取到了鎖，則繼續保持偏向鎖狀態
若經過一次 CAS 操作未爭取到鎖，意味著還有其他的線程也在競爭這個鎖，此時就進行鎖升級，升級為輕量級鎖

輕量級鎖是自適應自旋鎖

自旋獲取鎖成功，是保持輕量級鎖狀態嗎？？
自旋獲取鎖失敗，則進入重量級鎖

5.1 成本的差異

不同的鎖性能成本不同：

1）重量級鎖：線程在用戶態到內核態之間切換成本高

鎖不能降級，鎖變成重量級鎖之后，就一直要作為重量級鎖使用嗎？那還怎么自適應自旋？？

Java 鎖優化--JVM 鎖降級里說道：鎖降級確實是會發生的，當 JVM 進入安全點（SafePoint）的時候，會檢查是否有閑置的 Monitor，然后試圖進行降級。

2）其他的鎖都是為了更小的開銷

偏向鎖：一次 CAS 操作，修改一下鎖中的字段，就被標識為拿得到了鎖
輕量鎖：一次 CAS 操作拿不到鎖，那就自旋空轉多次 CAS 操作，會稍稍費一點 CPU，但是能更快的拿到鎖；自適應自旋后，還拿不到鎖，那就只能使用重量級鎖了。
自旋鎖：許多情況下，共享數據的鎖定狀態持續時間較短，切換線程不值得，通過讓線程執行循環等待鎖的釋放，不讓出 CPU。如果得到鎖，就順利進入臨界區。如果還不能獲得鎖，那就會將線程在操作系統層面掛起，這就是自旋鎖的優化方式。但是它也存在缺點：如果鎖被其他線程長時間占用，一直不釋放 CPU，會帶來許多的性能開銷。
自適應自旋鎖：這種相當于是對上面自旋鎖優化方式的進一步優化，它的自旋的次數不再固定，其自旋的次數由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態來決定，這就解決了自旋鎖帶來的缺點。