基於synchronized鎖的深度解析

1. 問題引入

小夥伴們都接觸過線程，也都會使用線程，今天咱們要講的是線程安全相關的內容，在這以前咱們先來看一個簡單的代碼案例。


代碼案例：

/**
 * @url: i-code.online
 * @author: AnonyStar
 * @time: 2020/10/14 15:39
 */
public class ThreadSafaty {
    //共享變量
    static int count = 0;

    public static void main(String[] args) {

        //建立線程
        Runnable runnable = () -> {
            for (int i = 0; i < 5; i++) {
                count ++;
                try {
                    Thread.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        };

        for (int i = 0; i < 100; i++) {
            new Thread(runnable,"Thread-"+i).start();
        }

        try {
            Thread.sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("count = "+ count);
    }
}

執行結果：



問題說明：
在上面的代碼中咱們能夠看到，定義了一個線程 runnable 裏面對公共成員變量進行 ++ 操做，並循環五次，每次睡眠一毫秒，以後咱們在主線程 main 方法中建立一百個線程而且啓動，而後主線程睡眠等待五秒以此來等全部的線程執行結束。咱們預期結果應該是 500 。可是實際執行後咱們發現 count 的值是不固定的 ，是小於 500 的，這裏就是多線程並行致使的數據安全性問題！

經過上述案例咱們能夠清楚的看到線程安全的問題，那麼咱們想一想是否有什麼辦法來避免這種安全問題尼 ？咱們能夠想到致使這種安全問題的緣由是由於咱們訪問了共享數據，那麼咱們是否能將線程訪問共享數據的過程變成串行的過程那麼不就是不存在這個問題了。這裏咱們能夠想到以前說的 鎖 ，咱們知道鎖是處理併發的一種同步方式，同時他也具有互斥性，在Java中實現加鎖是經過 synchronized 關鍵字

2. 鎖的基本認識

2.1 Synchronized 的認識

在Java 中咱們知道有一個元老級的關鍵字 synchronized ，它是實現加鎖的關鍵，可是咱們一直都認爲它是一個重量級鎖，其實早在 jdk1.6 時就對其進行了大量的優化，讓它已經變成很是靈活。也再也不一直是重量級鎖了，而是引入了 偏向鎖 和 輕量級鎖。 關於這些內容咱們將詳細介紹。

synchronized的基礎使用

• synchronized 修飾實例方法，做用於當前實例加鎖
• synchronized 修飾靜態方法，做用於當前類對象加鎖，
• synchronized 修飾代碼塊，指定加鎖對象，對給定對象加鎖，

在上述狀況中，咱們要進入被 synchronized 修飾的同步代碼前，必須得到相應的鎖，其實這也體現出來針對不一樣的修飾類型，表明的是鎖的控制粒度

• 咱們修改一下前面咱們寫的案例，經過使用 synchronized 關鍵字讓其實現線程安全

//建立線程
        Runnable runnable = () -> {
            synchronized (ThreadSafaty.class){
                for (int i = 0; i < 5; i++) {
                    count ++;
                    try {
                        Thread.sleep(1);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }

        };

只須要添加 synchronized (ThreadSafaty.class) 的修飾，將操做的內容放入代碼塊中，那麼就會實現線程安全

• 經過上面的實踐咱們能夠直觀感覺 synchronized 的做用，這是咱們平時開發中常規使用，你們有沒有過疑問，這個鎖究竟是怎麼存儲實現的？那麼下面咱們將對探索其中的奧祕

Java中鎖的實現

• 咱們知道鎖是具備互斥性(Mutual Exclusion)的 ，那麼它是在什麼地方標記存在的尼？
• 咱們也知道多個線程均可以獲取鎖，那麼鎖必然是能夠共享的
• 咱們最熟悉的 synchronized 它獲取鎖的過程究竟是怎麼樣的呢？它的鎖是如何存儲的呢？

• 咱們能夠注意觀察 synchronized 的語法，能夠看到 synchronized(lock) 是基於 lock 的生命週期來實現控制鎖粒度的，這裏必定要理解，咱們得到鎖時都時一個對象，那麼鎖是否是會和這個對象有關係呢？
• 到這裏爲止，咱們將全部的關鍵信息都指向了對象，那麼咱們有必要以此爲切入點，來首先了解對象在 jvm 中的分佈形式，再來看鎖是怎麼被實現的。

對象的內存佈局

• 這裏咱們只談論對象在 Heap 中的佈局，而不會涉及過多的關於對象的建立過程等細節，這些內容咱們再單獨文章詳細闡述，能夠關注 i-code.online 博客或wx "雲棲簡碼"

• 在咱們最經常使用的虛擬機 hotspot 中對象在內存中的分佈能夠分爲三個部分：對象頭（Header）、實列數據（Instance Data）、對其填充（Padding）

• 經過上述的圖示咱們能夠看到，對象在內存中，包含三個部分，   其中對象頭內分爲 對象標記與類元信息，在對象標記中主要包含如圖所示 hashcode、GC分代年齡、鎖標記狀態、偏向鎖持有線程id、線程持有的鎖(monitor)等六個內容，這部分數據的長度在 32 位和64位的虛擬機中分別爲32bit 和 64bit，在官方將這部分稱爲 Mark Word 。
• Mark Word 實際是一中能夠動態定義的數據結構，這樣可讓極小的空間存儲儘可能多的數據，根據對象的狀態複用本身的內存空間，好比在32位的虛擬機中，若是對象未被同步鎖鎖定的狀態下， Mark Word 的32個比特存儲單元中，25個用於存儲哈希碼，4個用於存儲GC分代年齡，2個存鎖標記位，1個固定位0，針對各個狀態下的分佈能夠直觀的參看下面的圖表

32位HotSpot虛擬機對象頭Mark Word

鎖狀態	25bit		4bit	1bit (是不是偏向鎖)	2bit (鎖標誌位)
	23bit	2bit
無鎖	對象的HashCode		分代年齡	0	01
偏向鎖	線程ID	Epoch(偏向時間戳)	分代年齡	1	01
輕量級鎖	指向棧中鎖記錄的指針				00
重量級鎖	指向重量級鎖的指針				10
GC標記	空				11

上述說的是32位虛擬機，須要注意。關於對象頭的另外一部分是類型指針，這裏咱們不展開再細說了，想了解的關注 i-code.online ,會持續更新相關內容😁😊

• 下面內容會涉及到源碼的查看，須要提早下載源碼，若是你不知道如何來下載，能夠參看《下載JDK 與 Hotspot 虛擬機源碼》這篇文章，或者關注 雲棲簡碼。
• 在咱們熟悉的虛擬機 Hotspot 中實現 Mark Word 的代碼在 markOop.cpp 中，咱們能夠看下面片斷，這是描述了虛擬機中MarkWord 的存儲佈局：

• 當咱們在 new 一個對象時，虛擬機層面實際會建立一個 instanceOopDesc 對象，咱們熟悉的 Hotspot 虛擬機採用了 OOP-Klass 模型來描述 Java 對象實例，其中 OOP 就是咱們熟悉的普通對象指針，而 Klass 則是描述對象的具體類型，在Hotspot 中分別用 instanceOopDesc 和 arrayOopDesc 來描述，其中arrayOopDesc 用來描述數組類型，

• 對於 instanceOopDesc 的實現咱們能夠從 Hotspot 源碼中找到。對應在 instanceOop.hpp 文件中，而相應的 arrayOopDesc 在 arrayOop.hpp 中，下面咱們來看一下相關的內容：

• 咱們能夠看到 instanceOopDesc 繼承了 oopDesc，而 oopDesc 則定義在 oop.hpp 中，

• 上述圖示中咱們能夠看到相關信息，具體也註釋了文字，那麼接下來咱們要探索一下 _mark 的實現定義了，以下，咱們看到它是markOopDesc

• 經過代碼跟進咱們能夠在找到 markOopDesc 的定義在 markOop.hpp 文件中，以下圖所示：

• 在上述圖片中咱們能夠看到，內部有一個枚舉。記錄了 markOop 中存儲項，因此在咱們實際開發時，當 synchronized 將某個對象做爲鎖時那麼以後的一系列鎖的信息都和 markOop 相關。如上面表格中 mark word的分佈記錄所示具體的各個部分的含義
• 由於咱們建立對象時實際在jvm層面都會生成一個native 的c++ 對象 oop/oopdesc 來映射的，而每一個對象都帶有一個 monitor 的監視器對象，能夠在 markOop.hpp 中看到，其實在多線程中搶奪鎖就是在爭奪 monitor 來修改相應的標記

Synchronized 的深刻

• 在 Java 中 synchronized 是實現互斥同步最基本的方法，它是一個塊結構(Block Structured)的同步語法，在通過javac 編譯後會在塊的先後分別造成 monitorrenter 和 monitorexit 兩個字節碼指令，而它們又都須要一個 reference 類型的參數來指明鎖對象，具體鎖對象取決於 synchronized 修飾的內容，上面已經說過不在闡述。

《深刻理解Java虛擬機》中有這樣的描述：
根據《Java虛擬機規範》的要求，在執行monitorenter指令時，首先要去嘗試獲取對象的鎖。若是 這個對象沒被鎖定，或者當前線程已經持有了那個對象的鎖，就把鎖的計數器的值增長一，而在執行 monitorexit指令時會將鎖計數器的值減一。一旦計數器的值爲零，鎖隨即就被釋放了。若是獲取對象 鎖失敗，那當前線程就應當被阻塞等待，直到請求鎖定的對象被持有它的線程釋放爲止

• 因此被 synchronized 修飾的代碼塊對同一個線程是可重入的，這也就避免了同線程反覆進入致使死鎖的可能
• 在synchronized 修飾的代碼塊直接結束釋放鎖以前，會阻塞後面的其餘線程

爲何說synchronized是重量級鎖

• 從執行成原本說，持有鎖是一個重量級(Heavy-Weight)的操做過程，由於在Java中線程都是映射到操做系統的原生內核線程上的，若是要阻塞和喚醒某一個線程都須要通過操做系統來調度，而這就不可避免的會進行用戶態和內核態的轉換，可是這種轉換是很是耗費處理器時間的，尤爲對於自己業務代碼簡單的程序，可能在這裏耗費的時間比業務代碼自身執行的時間還長，因此說synchronized 是一個重量級的操做，不過在 jdk6 後對其作了大量的優化，讓它再也不顯得那麼重

鎖的優化

• 在 JDK5 升級到 JDK6 後進行一系列關於鎖的改進，經過多種技術手段來優化鎖，讓 synchronized 再也不像之前同樣顯的很重，這其中涉及到適應性自旋（Adaptive Spinning）、鎖消除(Lock Elimination)、鎖膨脹(Lock Coarsening)、輕量級鎖(LightWeight Locking)、偏向鎖(Biased Locking)等，這些都是用來優化和提升多線程訪問共享數據的競爭問題。

鎖消除

• 鎖消除是虛擬機在即時編譯器運行時對一些代碼要求同步，可是被檢測到不可能存在共享數據競爭的鎖進行消除，其中主要的斷定依據是基於逃逸分析技術來實現的，關於這塊內容不在這裏展開，後續相關文章介紹。這裏咱們簡單理解就是，若是一段代碼中，在堆上的數據都不會逃逸出去被其餘線程訪問到，那麼就能夠把它們看成棧上的數據來對來，認爲它們都是線程私有的，從而也就不須要同步加鎖了，

• 關於代碼中變量是否逃逸，對虛擬機來講須要經過複雜分析才能獲得，可是對咱們開發人員來講仍是相對直觀的，那可能有人會疑惑既然開發人員能清楚還爲何要多餘的加鎖同步呢？，其實實際上，程序上很是多的同步措施並非咱們開發人員本身加入的，而是 java 內部就有大量的存在，好比下面這個典型的例子，下面展現的是字符串的相加

private String concatString(String s1,String s2,String s3){
        return s1 + s2 + s3;
    }

• 咱們知道String 類是被 final 修飾的不可變類，因此對於字符串的相加都是經過生成新的String 對象來試試先的，所以編譯器會對這種操做作優化處理，在JDK5 以前會轉換爲 StringBuffer 對象的append() 操做，而在JDK5 及其以後則轉換爲StringBuilder 對象來操做。因此上述代碼在jdk5可能會變成以下：

private String concatString(String s1,String s2,String s3){
        StringBuffer sb = new StringBuffer();
        sb.append(s1);
        sb.append(s2);
        sb.append(s3);
        return sb.toString();
    }

• 這時候，就能夠看到，對於StringBuffer。append() 方法是一個同步方法，帶有同步快，鎖對象就是 sb ,這時候虛擬機經過分析發現 sb 的做用域被限制在方法內部，而不可能逃逸出方法外讓其餘線程訪問到，因此這是在通過服務端編譯器的即時編譯後，這段代碼的全部同步措施都會失效而直接執行。

上述代碼是爲了方便演示而選擇了String，實際來講在jdk5以後都是轉換爲Stringbuilder ,也就不存在這個問題了，可是在jdk中相似這種仍是很是多的。

鎖粗化

• 關於鎖的粗話其實也是很簡單的理解，咱們在開發時老是推薦同步代碼塊要做用範圍儘可能小，儘可能只在共享數據的實際做用域中才進行同步，這樣的目的是爲了儘量減小同步的操做，讓其餘線程能更快的拿到鎖
• 這是多大多數狀況，可是總有一些特殊狀況，好比在某個系列連續操做的都是對同一個對象反覆的加鎖和解鎖，那麼這會致使沒必要要的性能損耗
• 也如同上面String 的案例，在連續的append 操做都是零碎的同步塊，並且都是同一個鎖對象，這時候會將鎖的範圍擴展，到整個操做序列外部，也就是第一個append 以前到最後一個append 操做以後，將這些所有放入一個同步鎖中就能夠了，這樣就避免了屢次的鎖獲取和釋放。

自旋鎖

• 經過以前的瞭解，咱們知道掛起線程和恢復線程都是會涉及到用戶態和內核態的轉換，而這些都是很是耗時的，這會直接影響虛擬機的併發性能。
• 在咱們平時開發中，若是共享數據的鎖定狀態只會持續很短的時間，那麼爲了這很短的時間而去掛起阻塞線程是很是浪費資源的。尤爲如今的電腦都基本是多核處理器，因此在這種前提下，咱們是是否可讓另外一個請求鎖對象的線程不去掛起，而是稍微等一下，這個等待並不會放棄CPU 的執行時間。等待觀察持有鎖的線程是否能很快的釋放鎖，其實這個等待就比如是一個空的循環，這種技術就是一個所謂的自旋鎖

• 自旋鎖在JDK6 中及已是默認開啓的了，在jdk4時就引入了。自旋鎖並非阻塞也代替不了阻塞。
• 自旋鎖對處理器數量有必定的要求，同時它是會佔用CPU 時間的，雖然它避免了線程切換的開銷，可是這之間時存在平衡關係的，假如鎖被佔用的時間很短那麼自旋就很是有價值，會節省大量的時間開銷，可是相反，若是鎖佔用的時間很長，那麼自旋的線程就會白白消耗處理器資源，形成性能的浪費。
• 因此自旋鎖必須有一個限度，也就是它自旋的次數，規定一個自旋次數，若是超過這個次數則再也不自旋轉而用傳統方式掛起線程，
• 自旋的次數默認時十次。可是咱們也能夠經過 -XX: PreBlockSpin 參數來自定義設置

自適應自旋鎖

• 在前面咱們知道能夠自定義自旋次數，可是這個很難有個合理的值，畢竟在程序中怎麼樣的狀況都有，咱們不可能經過全局設置一個。因此在JDK6 以後引入了自適應自旋鎖，也就是對原有的自旋鎖進行了優化
• 自適應自旋的時間再也不是固定的，而是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態決定的，若是在同一個鎖對象上，自旋等待剛剛成功得到過鎖，而且支持有鎖的線程正在運行中，那麼虛擬機就會任務此次自旋也極有再次得到鎖，那麼就會容許自旋的持續時間更長
• 相應的 ，若是對於某個鎖，自旋得到鎖的次數很是少，那麼在以後要獲取鎖的時候將直接忽略掉自旋的過程進而直接阻塞線程避免浪費處理器資源

輕量級鎖

• 輕量級鎖也是 JDK6 時加入的新的鎖機制，它的輕量級是相對於經過操做系統互斥量來實現的傳統鎖而言的，輕量級鎖也是一種優化，而不是能替代重量級鎖，輕量級鎖的涉及初衷就是在沒有多線程競爭下減小傳統重量級鎖使用操做系統互斥量產生的性能消耗。
• 要想了解輕量級鎖咱們必須對對象在Heap 中的分佈瞭解，也就是上面說到的內容。

輕量級鎖加鎖

• 當代碼執行到同步代碼塊時，若是同步對象沒有被鎖定也就是鎖標誌位爲01 狀態，那麼虛擬機首先將在當前線程的棧幀中創建一個名爲鎖記錄Lock Record 的空間
• 這塊鎖記錄空間用來存儲鎖對象目前的 Mark Word 的拷貝，官方給其加了個Displaced 的前綴，即 Displaced Mark Word ，以下圖所示，這是在CAS 操做以前堆棧與對象的狀態

• 當複製結束後虛擬機會經過CAS 操做嘗試把對象的Mark Word 更新爲指向Lock Record 的指針，若是更新成功則表明該線程擁有了這個對象的鎖，而且將Mark Word 的鎖標誌位（最後兩個比特）轉變爲 「00」，此時表示對象處於輕量級鎖定狀態，此時的堆棧與對象頭的狀態以下：

• 若是上述操做失敗了，那說明至少存在一條線程與當前線程競爭獲取該對象的鎖，虛擬機會首先檢查對象的Mark Word 是否指向當前線程的棧幀，若是是，則說明當前線程已經擁有了這個對象的鎖，那麼直接進入同步代碼塊執行便可。不然則說明這個對象已經被其餘線程搶佔了。
• 若是有超過兩條以上的線程爭奪同一個鎖的狀況，那麼輕量級鎖就再也不有效，必須膨脹爲重量級鎖，鎖的標記位也變爲「10」，此時Mark Word 中存儲的就是指向重量級鎖的指針，等待的線程也必須進入阻塞狀態

輕量級鎖的解鎖

• 輕量級鎖的解鎖一樣是經過CAS 操做來進行的
• 若是對象的 Mark Word 仍然指向線程的鎖記錄，那麼就用CAS 操做把對象當前的 Mark Word 和線程中複製的 Displaced Mark Word 替換回來
• 若是替換成功則整個同步過程結束，若失敗則說明有其餘線程正在嘗試獲取該鎖，那就要在釋放鎖的同時，喚醒被掛起的線程

輕量級鎖適用的場景是對於絕大部分鎖在整個同步週期內都是不存在競爭的，由於若是沒有競爭，輕量級鎖即可以經過 CAS 操做成功避免了使用互斥量的開銷，可是若是確實存在鎖競爭，那麼除了互斥量自己的開銷外還得額外發生了 CAS 操做的開銷，這種狀況下反而比重量級鎖更慢

• 下面經過完整的流程圖來直觀看一下輕量級鎖的加鎖解鎖及膨脹過程

偏向鎖

• 偏向鎖也是JDK6 引入的一種鎖優化技術，若是說輕量級鎖是在無競爭狀況下經過CAS 操做消除了同步使用的互斥量，那麼偏向鎖則是再無競爭狀況下把整個同步都給消除掉了，連CAS 操做都再也不去作了，能夠看出這比輕量級鎖更加輕
• 從對象頭的分佈上看，偏向鎖中是沒有哈希值的而是多了線程ID與Epoch 兩個內容
• 偏向鎖的意思就是鎖會偏向第一個得到它的線程，若是接下來的執行過程當中該鎖一直沒有被其餘線程獲取，那麼只有偏向鎖的線程將永遠不須要再進行同步

偏向鎖的獲取和撤銷

• 當代碼執行到同步代碼塊時，在第一次被線程執行到時，鎖對象是第一次被線程獲取，此時虛擬機會將對象頭中的鎖標誌改成「01」，同時把偏向鎖標誌位改成「1」，表示當前鎖對象進入偏向鎖模式。
• 接下來線程經過CAS 操做來將這個幀的線程ID記錄到對象頭中，若是CAS 成功了。則持有鎖對象的線程再以後進入同步代碼再也不進行任何同步操做（如獲取鎖解鎖等操做）。每次都會經過判斷當前線程與鎖對象中記錄的線程id是否一致。
• 若是 上述的 CAS 操做失敗了，那說明確定存在另一個線程在獲取這個鎖，而且獲取成功了。這種狀況下說明存在鎖競爭，則偏向模式立刻結束，偏向鎖的撤銷，須要等待全局安全點(在這個時間點上沒有正在執行的字節碼)。它會首先暫停擁有偏向鎖的線程，會根據鎖對象是否處於鎖定狀態來決定是否撤銷偏向也就是將偏向鎖標誌位改成「0」，若是撤銷則會變爲未鎖定（「01」）或者輕量級鎖（「00」）
• 若是鎖對象未鎖定，則撤銷偏向鎖（設置偏向鎖標誌位爲「0」），此時鎖處於未鎖定不能夠偏向狀態，由於具備哈希值，進而變爲輕量級鎖
• 若是鎖對象還在鎖定狀態則直接進入輕量級鎖狀態

偏向鎖的開關

• 偏向鎖在JDK6 及其以後是默認啓用的。因爲偏向鎖適用於無鎖競爭的場景，若是咱們應用程序裏全部的鎖一般狀況下處於競爭狀態，能夠經過JVM參數關閉偏向鎖：-XX:-UseBiasedLocking=false，那麼程序默認會進入輕量級鎖狀態。
• 若是要開啓偏向鎖能夠用： -XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0

重量級鎖

• 重量級鎖也就是上述幾種優化都無效後，膨脹爲重量級鎖，經過互斥量來實現，咱們先來看下面的代碼

• 上面代碼是一個簡單使用了synchronized 的代碼，咱們經過字節碼工具能夠看到右側窗口。咱們發現，在同步代碼塊的先後分別造成了monitorenter 和 monitorexit 兩條指令
• 在Java對現中都會有一個monitor 的監視器，這裏的monitorenter 指令就是去獲取一個對象的監視器。而相應的monitorexit 則表示釋放監視器monitor 的全部權，容許被其餘線程來獲取
• monitor 是依賴於系統的 MutexLock (互斥鎖) 來實現的，當線程阻塞後進入內核態事，就會形成系統在用戶態和內核態之間的切換，進而影響性能

總結

• 上面是闡述了關於synchronized 鎖的一些優化與轉換，在咱們開啓偏向鎖和自旋時，鎖的轉變是 無鎖 -> 偏向鎖 -> 輕量級鎖 -> 重量級鎖，
• 自旋鎖實際是一種鎖的競爭機制，而不是一種狀態。在偏向鎖和輕量級鎖中都使用到了自旋
• 偏向鎖適用於無鎖競爭的場景，輕量級鎖適合無多個線程競爭的場景
• 偏向鎖和輕量級鎖都依賴與CAS操做，可是偏向鎖中只有在第一次時纔會CAS操做
• 當一個對象已經被計算過一致性哈希值時，那麼這個對象就不再沒法進入到偏向鎖狀態了，若是對象正處於偏向鎖狀態，而接收到計算哈希值的請求，那麼他的偏向鎖狀態會被當即撤銷，而且會膨脹爲重量級鎖。這要是爲何偏向鎖狀態時MarkWord 中沒有哈希值

---

本文由AnonyStar 發佈,可轉載但需聲明原文出處。
歡迎關注微信公帳號 ：雲棲簡碼 獲取更多優質文章
更多文章關注筆者博客 ： 雲棲簡碼 i-code.online