Monitor實現的鎖屬于重量級鎖，你了解過鎖升級嗎？

前面我們說了  synchronized 底層由monitor實現的，它那 synchronized 到底鎖的是什么呢？隨著 JDK 版本的升級，synchronized 又做出了哪些改變呢？“synchronized 性能很差”的謠言真的存在嗎？

在介紹以上內容之前，我們要先知道重量級鎖概念。

重量級鎖

當另外一個線程執行到同步塊的時候，由于它沒有對應 monitor 的所有權，就會被阻塞，此時控制權只能交給操作系統，也就會從 user mode 切換到 kernel mode, 由操作系統來負責線程間的調度和線程的狀態變更, 這就需要頻繁的在這兩個模式下切換（上下文轉換）。有點競爭就找內核的行為很不好，會引起很大的開銷，所以大家都叫它重量級鎖，自然效率也很低,這也就給很多小伙伴留下了一個印象 —— synchronized 關鍵字相比于其他同步機制性能不好，但其實不然。

• Monitor實現的鎖屬于重量級鎖，里面涉及到了用戶態和內核態的切換、進程的上下文切換，成本較高，性能比較低。
• 在JDK 1.6引入了兩種新型鎖機制：偏向鎖和輕量級鎖，它們的引入是為了解決在沒有多線程競爭或基本沒有競爭的場景下因使用傳統鎖機制帶來的性能開銷問題。

一、MarkWord

在JVM虛擬機中，對象在內存中存儲的布局可分為3塊區域：對象頭（Header）、實例數據（Instance Data）和對齊填充。

圖片

我們需要重點分析MarkWord對象頭,因為Markword 是保存鎖狀態的關鍵，對象鎖狀態可以從偏向鎖升級到輕量級鎖，再升級到重量級鎖，加上初始的無鎖狀態，可以理解為有 4 種狀態。想在一個對象中表示這么多信息自然就要用位來存儲。

圖片

• hashcode：25位的對象標識Hash碼
• age：對象分代年齡占4位
• biased_lock：偏向鎖標識，占1位 ，0表示沒有開始偏向鎖，1表示開啟了偏向鎖

thread：持有偏向鎖的線程ID，占23位

• epoch：偏向時間戳，占2位
• ptr_to_lock_record：輕量級鎖狀態下，指向棧中鎖記錄的指針，占30位
• ptr_to_heavyweight_monitor：重量級鎖狀態下，指向對象監視器Monitor的指針，占30位

我們可以通過lock的標識，來判斷是哪一種鎖的等級

• 后三位是001表示無鎖
• 后三位是101表示偏向鎖
• 后兩位是00表示輕量級鎖
• 后兩位是10表示重量級鎖

二、輕量級鎖

在很多的情況下，在Java程序運行時，同步塊中的代碼都是不存在競爭的，不同的線程交替的執行同步塊中的代碼。這種情況下，用重量級鎖是沒必要的。因此JVM引入了輕量級鎖的概念。

如果 CPU 通過 CAS（后面會細講，戳鏈接直達）就能處理好加鎖/釋放鎖，這樣就不會有上下文的切換。

但是當競爭很激烈，CAS 嘗試再多也是浪費 CPU，權衡一下，不如升級成重量級鎖，阻塞線程排隊競爭，也就有了輕量級鎖升級成重量級鎖的過程。

圖片

作為程序員的我們最喜歡用代碼說話，貼心的 openjdk 官網提供了可以查看對象內存布局的工具 JOL (java object layout)，我們直接通過 Maven 引入到項目中。

<dependency>
      <groupId>org.openjdk.jol</groupId>
      <artifactId>jol-core</artifactId>
      <version>0.14</version>
  </dependency>

public class SyncSample {


    private static Object LOCK = new Object();

    public static void main(String[] args) {


        System.out.println("----------未進入同步塊，MarkWord 為：----------");

        System.out.println(ClassLayout.parseInstance(LOCK).toPrintable());


        synchronized (LOCK) {
            System.out.println("----------進入同步塊，MarkWord 為：----------");
            System.out.println(ClassLayout.parseInstance(LOCK).toPrintable());
        }
    }

}

圖片

2.1 加鎖流程

1.在線程棧中創建一個Lock Record，將其obj字段指向鎖對象。

圖片

2.通過CAS指令將Lock Record的地址存儲在對象頭的mark word中（數據進行交換），如果對象處于無鎖狀態則修改成功，代表該線程獲得了輕量級鎖。

圖片

3.如果是當前線程已經持有該鎖了，代表這是一次鎖重入。設置Lock Record第一部分為null，起到了一個重入計數器的作用。

圖片

4.如果CAS修改失敗，說明發生了競爭，需要膨脹為重量級鎖。

2.2 解鎖流程

1.遍歷線程棧,找到所有obj字段等于當前鎖對象的Lock Record。

2.如果Lock Record的Mark Word為null，代表這是一次重入，將obj設置為null后continue。

圖片

3.如果Lock Record的 Mark Word不為null，則利用CAS指令將對象頭的mark word恢復成為無鎖狀態。如果失敗則膨脹為重量級鎖。

圖片

三、偏向鎖

輕量級鎖在沒有競爭時（就自己這個線程），每次重入仍然需要執行 CAS 操作。Java 6 中引入了偏向鎖來做進一步優化：只有第一次使用 CAS 將線程 ID 設置到對象的 Mark Word 頭，之后發現這個線程 ID 是自己的就表示沒有競爭，不用重新 CAS。以后只要不發生競爭，這個對象就歸該線程所有。

圖片

可是多線程環境，也不可能只有同一個線程一直獲取這個鎖，其他線程也是要干活的，如果出現多個線程競爭的情況，就會有偏向鎖升級的過程。

1.在線程棧中創建一個Lock Record，將其obj字段指向鎖對象。

圖片

2.通過CAS指令將Lock Record的線程id存儲在對象頭的mark word中，同時也設置偏向鎖的標識為101，如果對象處于無鎖狀態則修改成功，代表該線程獲得了偏向鎖。

圖片

3.如果是當前線程已經持有該鎖了，代表這是一次鎖重入。設置Lock Record第一部分為null，起到了一個重入計數器的作用。與輕量級鎖不同的時，這里不會再次進行cas操作，只是判斷對象頭中的線程id是否是自己，因為缺少了cas操作，性能相對輕量級鎖更好一些。

圖片

思考:偏向鎖可以繞過輕量級鎖，直接升級到重量級鎖嗎？

四、面試題

面試官:Monitor實現的鎖屬于重量級鎖，你了解過鎖升級嗎？

Java中的synchronized有無鎖(無鎖就是沒有對資源進行鎖定，任何線程都可以嘗試去修改它)、偏向鎖、輕量級鎖、重量級鎖四種形式，偏向鎖、輕量級鎖、重量級鎖分別對應了鎖只被一個線程持有、不同線程交替持有鎖、多線程競爭鎖三種情況