我是「大王」，是一人之下萬人之上的真男人！每次只能有一個王妃獲得寵信與我夜夜笙歌。

王妃們會想方設法爭寵獲得與我共眠的機會，所以我需要一個總管來幫我合理的調度挑選一個「王妃」，他的名字叫 synchronized。

假如 synchronized 是「王」身邊的「大總管」，那么 Thread 就像是他后宮的王妃。

今日聽「碼哥」胡言亂語解開 synchronized 大總管如何調度「王妃」獲取與王夜夜笙歌的陪伴。

王妃不同狀態的變化到底經歷了什么？且看 synchronized 大總管又采取了哪些手段更加高效調度一個王妃，宮斗還有 30 秒到達戰場！！！

故事的開端

「碼哥」通過幾個故事，讓讀者朋友完全掌握 synchronized 的鎖優化（偏向鎖 -> 輕量級鎖 -> 重量級鎖）原理以及線程在 6 種狀態之間轉換的奧秘。

抽象出三個概念：Thread 對應后宮佳麗「王妃」，synchronized 是后宮大總管負責調度王妃獲得與「王」陪伴的機會，「王」則是被王妃們想要競爭的資源。

當然整個「皇宮」就是 Java JVM 虛擬機。

王妃的六種狀態

后宮佳麗等級森嚴，王妃們在這場權貴的游戲中每個人的目的都是為獲取「王」寵愛，在這場宮斗劇中自身的狀態也隨著不同的遭遇有著不同的變化。

「Thread 王妃」的生命周期中一共有 6 種狀態：

• New（新入宮）：Thread state for a thread which has not yet started.
• Runnable 可運行、就緒：（身體舒適，準備好了），Java 中的 Runable 狀態對應操作系統線程狀態中的兩種狀態，分別是 Running 和 Ready，也就是說，Java 中處于 Runnable 狀態的線程有可能正在執行，也有可能沒有正在執行，正在等待被分配 CPU 資源。
• Blocked 阻塞（身體欠佳、被打入冷宮、來大姨媽了……）
• WAITING（等待）：（等待傳喚）
• Timed Waiting（計時等待）：在門外計時等待
• Terminated（終止）：嗝屁

線程狀態

王妃在任意時刻只能是其中的一種狀態，通過 getState() 方法獲取線程狀態。

1.New 新入宮

第一日

「王」微服私訪，駕車游玩，途徑桃花源。見風景宜人，如人間仙境。停車坐愛楓林晚，霜葉紅于二月花。

此時此刻，一女子媚眼含羞合，丹唇逐笑開。風卷葡萄帶，日照石榴裙。

「王」擬寫一份招入宮的詔書，上面寫著new Thread() ，「香妃 Thread」的名分便正式成立。

New 表示線程被創建但是還沒有啟動的狀態，猶如「香妃」剛剛入宮，等待她后面的路程將是驚心動魄，蕩氣回腸。

皇宮（可以理解是 JVM）命令 synchronized 大總管為「香妃 Thread」分配寢宮（也就是分配內存），并初始化其身邊的「丫鬟」（初始化成員變量的值）。

2.Runnable 可運行、就緒

「香妃 Thread」安排好衣食住行之后，便準備好陪伴王了。

但是后宮佳麗很多，并不是所有人都能獲得陪伴權，「香妃」早已準備好，也在爭取可以獲得與「王」共舞的機會。

便主動告知 synchronized 大總管，自己琴棋書畫樣樣精通，并塞給它一個紅包，希望得到安排。

JVM 安排丫鬟為「香妃 Thread」沐浴更衣，抹上胭脂等待召喚（相當于線程的 start() 方法被調用）。

Java 虛擬機會為其創建方法調用?？沙绦蛴嫈灯?，等到調度運行，此刻線程就處于可運行狀態。

Java 中的 Runable 狀態對應操作系統線程狀態中的兩種狀態，分別是 Running 和 Ready，也就是說，Java 中處于 Runnable 狀態的線程有可能正在執行，也有可能沒有正在執行，正在等待被分配 CPU 資源。

注意：啟動線程使用 start() 方法，而不是 run() 方法。

調用 start()方法啟動線程，系統會把該 run 方法當成方法執行體處理。

需要切記的是：調用了線程的 run()方法之后，該線程就不在處于新建狀態，不要再次調用 start()方法，只能對新建狀態的線程調用start()方法，否則會引發 IllegaIThreadStateExccption 異常。

「香妃 Thread」沐浴更衣之后（被調用start() ）便焚香撫琴，可「淑妃 Thread」不跟示弱起舞弄影競爭陪伴權。

「香妃 Thread」畢竟新來的，喜新厭舊的渣男「王」甚是寵愛，「香妃 Thread」獲得了今晚的陪伴權，獲得 JVM 給予 CPU 分片后，執行 run()方法，該方法核心功能就是造娃…..

在造娃之前，「香妃 Thread」經歷了很多紛爭，狀態也一直在變化。稍有不慎，可能會進入 TERMINATED 狀態，直接玩完。

請繼續閱讀……

3.Waiting 等待、Timed Waiting 計時等待、Blocked 阻塞

「淑妃 Thread」也想獲得「王」的寵幸。那晚，她想與「王」造娃，王有要事需要處理，synchronized 大總管使用了 Object.wait() 技能卡，「香妃」只能等待王回來……

王處理完要事之后，synchronized 大總管使用 Object.notify() 解鎖，通知「香妃 Thread」可以一起和「王」么么噠了，此刻「香妃 Thread」竟然來大姨媽觸發了 Thread.join() 只好去上廁所，讓老王稍等片刻。

好不容易「香妃 Thread」處于 Runnable 態，但是被總管施展了 LockSupport.park() 技能卡，導致無法進入寢宮，狀態由 Runnable 變成了 Waiting 態。

「咔妃 Thread」由于太黑了，直接被 synchronized 大總管拒之門外，從 Runnable 變成 Blocked。

還有其他「妃」她們分別被以下技能卡命中進入，直接進入 TIMED_WAITING 狀態 ，一直等待有機會才能與王夜夜笙歌:

• Thread.sleep:
• Object.wait with timeout
• Thread.join with timeout
• LockSupport.parkNanos
• LockSupport.parkUntil

4.第二日

「咔妃」去韓國整容，變白了，得到了 syncronized 大總管的許可，得到一把叫 monitor 的令牌，由原先的 Blocked 變成了 Runnable ……

另外，有的王妃為了獲得陪伴權，或者想掌管后宮。陰謀詭計被識破，被判處 Terminated 刑罰，滅頂之災，強擼灰飛煙滅！

synchronized 總管如何提升效率翻牌

王妃們除了使用 LockSupport.unpark() 技能卡等獲取陪伴權，還可以通過由欽點大總管 synchronized 的令牌陪伴權。

面對三千佳麗，大總管必須要提高效率，不然將會累死而選不出一個王妃去陪伴老王，這可是要殺頭的。

因為在 Java 5 版本之前，synchronized 的篩選方法效率很差，一堆王妃跑進來吵著我行我上，秩序混亂，上一任總管就被殺頭了……

到了第 6 任 synchronized ，做了很大改善。運用了自適應自旋、鎖消除、鎖粗化、輕量級鎖、偏向鎖，效率大大提升。

1.自適應自旋

synchronized 通知王妃們過來排隊，「王」有急事需要處理，為了讓當前申請陪伴的咖妃“稍等一下”， synchronized 大總管會讓王妃自旋，少許的等待是值得的，「王」很快就會處理完成事情。

咖妃只需要每隔一段時間詢問大總管「王」是否處理好事情，一旦『王』歸來，那么自己就不需要進入阻塞態，獲得今日與王為伴。

避免因為要去通知多個王妃來競爭費時費力。

用一句話總結自旋鎖的好處，那就是自旋鎖用循環去不停地嘗試獲取鎖，讓線程始終處于 Runnable 狀態，節省了線程狀態切換帶來的開銷。

以下是自旋與非自旋獲取鎖的過程：

自旋與非自旋

AtomicInteger

在 Java 1.5 版本及以上的并發包中，也就是 java.util.concurrent 的包中，里面的原子類基本都是自旋鎖的實現。我們看下 AtomicInteger 類的定義：

public class AtomicInteger extends Number implements java.io.Serializable {
    private static final long serialVersionUID = 6214790243416807050L;

    // setup to use Unsafe.compareAndSwapInt for updates
    private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final long valueOffset;

    static {
        try {
            valueOffset = unsafe.objectFieldOffset
                (AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }

    private volatile int value;

    ......
}

各屬性的作用：

• unsafe：獲取并操作內存的數據。
• valueOffset：存儲 value 在 AtomicInteger 中的偏移量。
• value：存儲 AtomicInteger 的 int 值，該屬性需要借助 volatile 關鍵字保證其在線程間是可見的。

查看 AtomicInteger 的自增函數 incrementAndGet() 的源碼時，自增函數底層調用的是 unsafe.getAndAddInt()。

但是由于 JDK 本身只有 Unsafe.class，只通過 class 文件中的參數名，并不能很好的了解方法的作用，我們通過 OpenJDK 8 來查看 Unsafe 的源碼：

// JDK AtomicInteger 自增
public final int getAndIncrement() {
    return unsafe.getAndAddInt(this, valueOffset, 1);
}

// OpenJDK 8
// Unsafe.java
public final int getAndAddInt(Object o, long offset, int delta) {
   int v;
   do {
       v = getIntVolatile(o, offset);
   } while (!compareAndSwapInt(o, offset, v, v + delta));
   return v;
}

通過 do while 實現了自旋，getAndAddInt() 循環獲取給定對象 o 中的偏移量處的值 v，然后判斷內存值是否等于 v。

如果相等則將內存值設置為 v + delta，否則返回 false，繼續循環進行重試，直到設置成功才能退出循環，并且將舊值返回。

整個“比較 + 更新”操作封裝在 compareAndSwapInt() 中，在 JNI 里是借助于一個 CPU 指令完成的，屬于原子操作，可以保證多個線程都能夠看到同一個變量的修改值。

synchronized 大總管在 1.6 版本想出了自適應自旋鎖來解決長時間自旋的問題，防止一直傻傻等待傻傻的問。會根據最近自旋的成功率、失敗率。

如果最近嘗試自旋獲取某一把鎖成功了，那么下一次可能還會繼續使用自旋，并且允許自旋更長的時間；

但是如果最近自旋獲取某一把鎖失敗了，那么可能會省略掉自旋的過程，以便減少無用的自旋，提高效率。

2.鎖消除

淑妃詭詐，在公元 107 年一個夜黑風高的夜晚，串通后廚小哲子放了無色無味的黯然銷魂藥，妃子們有氣無力。

所以只剩下自己一個人向 synchronized 大總管申請與「王」共眠的機會，不需要繁瑣流程，直搗黃龍。直接面見老王，無需加鎖。

鎖消除即刪除不必要的加鎖操作。虛擬機即時編輯器在運行時，對一些“代碼上要求同步，但是被檢測到不可能存在共享數據競爭”的鎖進行消除。

根據代碼逃逸技術，如果判斷到一段代碼中，堆上的數據不會逃逸出當前線程，那么可以認為這段代碼是線程安全的，不必要加鎖。

public class SynchronizedTest {

    public static void main(String[] args) {
        SynchronizedTest test = new SynchronizedTest();

        for (int i = 0; i < 100000000; i++) {
            test.append("碼哥字節", "def");
        }
    }

    public void append(String str1, String str2) {
        StringBuffer sb = new StringBuffer();
        sb.append(str1).append(str2);
    }
}

雖然 StringBuffer 的 append 是一個同步方法，但是這段程序中的 StringBuffer 屬于一個局部變量，并且不會從該方法中逃逸出去（即 StringBuffer sb 的引用沒有傳遞到該方法外，不可能被其他線程拿到該引用），所以其實這過程是線程安全的，可以將鎖消除。

3.鎖粗化

「甄嬛 Thread」深得老王寵愛，被偏愛的都有恃無恐。

每次進出 synchronized 大總管的大門都需要驗證是否獲得 monitor 鎖，甄嬛進來后還喜歡出去外面走走過一會有進來看幾眼老王又出去，大總管也不用每次都要驗證，將限制的范圍就加大了，防止反復驗證。

如果一系列的連續操作都對同一個對象反復加鎖和解鎖，甚至加鎖操作是出現在循環體中的，那即使沒有出現線程競爭，頻繁地進行互斥同步操作也會導致不必要的性能損耗。

如果虛擬機檢測到有一串零碎的操作都是對同一對象的加鎖，將會把加鎖同步的范圍擴展（粗化）到整個操作序列的外部。

public class StringBufferTest {
    StringBuffer stringBuffer = new StringBuffer();

    public void append(){
        stringBuffer.append("關注");
        stringBuffer.append("公眾號");
        stringBuffer.append("碼哥字節");
    }
}

每次調用 stringBuffer.append 方法都需要加鎖和解鎖，如果虛擬機檢測到有一系列連串的對同一個對象加鎖和解鎖操作，就會將其合并成一次范圍更大的加鎖和解鎖操作，即在第一次 append 方法時進行加鎖，最后一次 append 方法結束后進行解鎖。

4.偏向鎖/輕量級鎖/重量級鎖

(1) 偏向鎖

老王偏愛「甄嬛」，synchronized 大總管便在一個叫 Mark Word 里柜子存儲鎖偏向的線程 ID，記錄著甄嬛的 ID，不需要執行繁瑣的翻牌流程。

只需要判斷下申請的王妃 ID 是否跟柜子里記錄的 ID 一致。

當一個線程訪問同步代碼塊并獲取鎖時，會在 Mark Word 里存儲鎖偏向的線程 ID。

在線程進入和退出同步塊時不再通過 CAS 操作來加鎖和解鎖，而是檢測 Mark Word 里是否存儲著指向當前線程的偏向鎖。

引入偏向鎖是為了在無多線程競爭的情況下盡量減少不必要的輕量級鎖執行路徑，因為輕量級鎖的獲取及釋放依賴多次 CAS 原子指令，而偏向鎖只需要在置換 ThreadID 的時候依賴一次 CAS 原子指令即可。

偏向鎖只有遇到其他線程嘗試競爭偏向鎖時，持有偏向鎖的線程才會釋放鎖，線程不會主動釋放偏向鎖。

偏向鎖的撤銷，需要等待全局安全點（在這個時間點上沒有字節碼正在執行），它會首先暫停擁有偏向鎖的線程，判斷鎖對象是否處于被鎖定狀態。

撤銷偏向鎖后恢復到無鎖（標志位為“01”）或輕量級鎖（標志位為“00”）的狀態。

偏向鎖在 JDK 6 及以后的 JVM 里是默認啟用的?？梢酝ㄟ^ JVM 參數關閉偏向鎖：-XX:-UseBiasedLocking=false，關閉之后程序默認會進入輕量級鎖狀態。

(2) 輕量級鎖

是指當鎖是偏向鎖的時候，被另外的線程所訪問，偏向鎖就會升級為輕量級鎖，其他線程會通過自旋的形式嘗試獲取鎖，不會阻塞，從而提高性能。

①在代碼進入同步塊的時候，如果同步對象鎖狀態為無鎖狀態（鎖標志位為“01”狀態，是否為偏向鎖為“0”），虛擬機首先將在當前線程的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用于存儲鎖對象目前的 Mark Word 的拷貝，官方稱之為 Displaced Mark Word。這時候線程堆棧與對象頭的狀態如下圖所示。

輕量級鎖

②拷貝 Object 對象頭中的 Mark Word 復制到 LockRecord 中。

③拷貝成功后，虛擬機將使用 CAS 操作嘗試將對象的 Mark Word 更新為指向 Lock Record 的指針，并將 Lock record 里的 owne r 指針指向 object mark word。如果更新成功，則執行步驟 4。

④如果這個更新動作成功了，那么這個線程就擁有了該對象的鎖，并且對象 Mark Word 的鎖標志位設置為“00”，即表示此對象處于輕量級鎖定狀態，這時候線程堆棧與對象頭的狀態如下圖所示。

⑤如果這個更新操作失敗了，虛擬機首先會檢查對象的 Mark Word 是否指向當前線程的棧幀，如果是就說明當前線程已經擁有了這個對象的鎖，那就可以直接進入同步塊繼續執行。否則說明多個線程競爭鎖，若當前只有一個等待線程，則可通過自旋稍微等待一下，可能另一個線程很快就會釋放鎖。但是當自旋超過一定的次數，或者一個線程在持有鎖，一個在自旋，又有第三個來訪時，輕量級鎖膨脹為重量級鎖，重量級鎖使除了擁有鎖的線程以外的線程都阻塞，防止 CPU 空轉，鎖標志的狀態值變為“10”，Mark Word 中存儲的就是指向重量級鎖（互斥量）的指針，后面等待鎖的線程也要進入阻塞狀態。

(3) 重量級鎖

如上輕量級鎖的加鎖過程步驟（5），輕量級鎖所適應的場景是線程近乎交替執行同步塊的情況，如果存在同一時間訪問同一鎖的情況，就會導致輕量級鎖膨脹為重量級鎖。Mark Word 的鎖標記位更新為 10，Mark Word 指向互斥量（重量級鎖）

Synchronized 的重量級鎖是通過對象內部的一個叫做監視器鎖（monitor）來實現的，監視器鎖本質又是依賴于底層的操作系統的 Mutex Lock（互斥鎖）來實現的。

而操作系統實現線程之間的切換需要從用戶態轉換到核心態，這個成本非常高，狀態之間的轉換需要相對比較長的時間，這就是為什么 Synchronized 效率低的原因。

(4) 鎖升級路徑

從無鎖到偏向鎖，再到輕量級鎖，最后到重量級鎖。結合前面我們講過的知識，偏向鎖性能最好，避免了 CAS 操作。

而輕量級鎖利用自旋和 CAS 避免了重量級鎖帶來的線程阻塞和喚醒，性能中等。

重量級鎖則會把獲取不到鎖的線程阻塞，性能最差。

鎖升級

綜上，偏向鎖通過對比 Mark Word 解決加鎖問題，避免執行 CAS 操作。而輕量級鎖是通過用 CAS 操作和自旋來解決加鎖問題，避免線程阻塞和喚醒而影響性能。重量級鎖是將除了擁有鎖的線程以外的線程都阻塞。