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

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/207942.html

標籤：Java

上一篇：Flink的sink實戰之二：kafka

下一篇：Spring Security 實戰干貨：OAuth2第三方授權初體驗

基于synchronized鎖的深度決議