synchronized 王的后宫总管，线程是王妃
假如 synchronized 是「王」身邊的「大總管」，那么 Thread 就像是他后宮的王妃。「王」每日只能選擇一個王妃陪伴，王妃們會想方設法爭寵獲得陪伴權，大總管需要通過一定的手段讓王「翻牌」一個「王妃」與王相伴。
今日胡言亂語解開 synchronized 大總管如何調度「王妃」陪伴「王」，王妃不同狀態的變化到底經歷了什么？且看 synchronized 大總管又采取了哪些手段更加高效「翻牌」一個王妃，宮斗還有 30 秒到達戰場！！！
王妃的 6 種狀態
synchronized 總管如何提升效率翻牌
自適應自旋
鎖消除
鎖粗化
偏向鎖/輕量級鎖/重量級鎖
鳴謝
抽象出三個概念：Thread 對應后宮佳麗「王妃」，synchronized 是后宮大總管負責安排調度王妃，「王」則是被王妃們想要競爭的資源。
王妃的 6 種狀態
后宮佳麗等級森嚴，王妃們在這場權貴的游戲中每個人的目的都是為獲取「王」寵愛，在游戲中自身的狀態也隨著變化。
就像生物從出生到長大、最終死亡的過程一樣，「王妃」也有自己的生命周期，在 王妃的生命周期中一共有 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() 方法獲取線程狀態。
New 新入宮
第一日
「王」微服私訪，駕車游玩，途徑桃花源。見風景宜人，如人間仙境。停車坐愛楓林晚，霜葉紅于二月花。此時此刻，一女子媚眼含羞合，丹唇逐笑開。風卷葡萄帶，日照石榴裙。從「王」面前走過，遭遇惡人。「王」拿起雙截棍哼哼哈嘿，飛檐走壁制服惡人，美人入懷，「香妃」便初入王宮。
「王」擬寫一份招入宮的詔書，上面寫著new Thread() ，「香妃」的名分便正式成立。New 表示線程被創建但是還沒有啟動的狀態，猶如「香妃」剛剛入宮，等待她后面的路程將是驚心動魄，蕩氣回腸。
此刻 「皇后」（可以理解是 JVM）命令趙公公，為「香妃」分配寢宮（也就是分配內存），并初始化其身邊的「丫鬟」（初始化成員變量的值）。
Runnable 可運行、就緒
「香妃」獲得「王」的詔書，安排好衣食住行之后，便準備好陪伴王了。但是后宮佳麗很多，并不是所有人都能獲得陪伴權，「香妃」早已準備好，也在爭取可以獲得與「王」共舞的機會。便主動告知趙公公，自己琴棋書畫樣樣精通。希望得到安排，所以便被趙公公調度。「皇后」安排丫鬟為「香妃」沐浴更衣，抹上胭脂等待召喚（相當于線程的 start() 方法被調用）。（Java 虛擬機會為其創建方法調用棧可程序計數器，等到調度運行）此刻線程就處于可運行狀態。
Java 中的 Runable 狀態對應操作系統線程狀態中的兩種狀態，分別是 Running 和 Ready，也就是說，Java 中處于 Runnable 狀態的線程有可能正在執行，也有可能沒有正在執行，正在等待被分配 CPU 資源。
如果一個正在運行的線程是 Runnable 狀態，當它運行到任務的一半時，執行該線程的 CPU 被調度去做其他事情，導致該線程暫時不運行，它的狀態依然不變，還是 Runnable，因為它有可能隨時被調度回來繼續執行任務。
注意：啟動線程使用 start() 方法，而不是 run() 方法。調用 start()方法啟動線程，系統會把該 run方法當成方法執行體處理。需要切記的是：調用了線程的 run()方法之后，該線程就不在處于新建狀態，不要再次調用 start()方法，只能對新建狀態的線程調用start()方法，否則會引發 IllegaIThreadStateExccption異常。
「香妃」沐浴更衣之后（被調用start() ）便焚香撫琴，「淑妃」不跟示弱起舞弄影競爭陪伴權，「香妃」畢竟新來的，喜新厭舊的渣男「王」甚是寵愛，「香妃」獲得了今晚的陪伴權，獲得「皇后」給予 CPU 分片后，執行 run()方法，該方法核心功能就是造娃…..
在造娃之前，「香妃」經歷了很多紛爭，狀態也一直在變化。稍有不慎，可能會進入 TERMINATED 狀態，直接玩完。請繼續閱讀……
Waiting 等待、Timed Waiting 計時等待、Blocked 阻塞
原先被得寵的「淑妃」敗給了新人「香妃」。當進入寢宮之時，準備造娃，王有要事需要處理，便使用了 Object.wait() 技能卡，「香妃」只能等待王回來……
王歸來為了解鎖之前對「香妃」釋放的Object.wait()技能便釋放 Object.notify() 解鎖卡通知「香妃」可以一起么么噠了，此刻「香妃」竟然大小便失禁觸發了 Thread.join() 只好去上廁所，讓老王稍等片刻。
「淑妃」當晚雖然已經處于Runnable 態，但是被總管施展了 LockSupport.park() 技能卡，導致無法進入寢宮，狀態由 Runnable 變成了 Waiting 態。今夜無緣老王！！！
「咔妃」由于太黑了，直接被 synchronized 大總管拒之門外，從 Runnable 變成 Blocked 。
還有其他「妃」被老王放鴿子了，跟他們說三更之后見，這個時間管理，羅某人表示不服。她們分別被以下技能卡命中進入，直接進入 TIMED_WAITING 狀態 :
Thread.sleep:
Object.wait with timeout
Thread.join with timeout
LockSupport.parkNanos
LockSupport.parkUntil
第二日
言歸正傳， 昨日「香妃」大小便失禁觸發了 Thread.join() 上完廁所后，跟王一番云雨，終于天亮。
而被 synchronized 大總管拒之門外，從 Runnable 變成 Blocked 的「淑妃」在第二日得到老王的寵信。因為「香妃」竟然關鍵時刻大小便失禁，所以便想著找昨天差點被翻牌的「淑妃」。所以今日「淑妃」獲得了老王留給她的 monitor 鎖，得到了 syncronized 大總管的許可，由昨天的 Blocked 變成了Runnable ……
另外，有的王妃為了獲得陪伴權，或者想掌管后宮。陰謀詭計被識破，被判處 Terminated 刑罰，滅頂之災，強擼灰飛煙滅！
?
synchronized 總管如何提升效率翻牌
王妃們除了使用 LockSupport.unpark() 等獲取陪伴權，還可以通過由老王欽點大總管synchronized 去翻牌獲得陪伴權。面對三千佳麗，大總管必須要提高效率，不然將會累死而選不出一個王妃去陪伴老王，這可是要殺頭的。
因為在 Java 5 版本之前，synchronized 的篩選方法效率很差，一堆王妃跑進來吵著我行我上，秩序混亂，堪比 OFO 退押金現場，上一任總管就被殺頭了……
到了第 6 任以后，做了很大改善。運用了自適應自旋、鎖消除、鎖粗化、輕量級鎖、偏向鎖，效率大大提升。
自適應自旋
通知王妃們過來排隊，或者重新叫一個王妃來都是需要操作系統切換 CPU來完成，耗費時間。
為了讓當前申請陪伴的咖妃“稍等一下”， 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?updatesprivate?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 版本想出了自適應自旋鎖來解決長時間自旋的問題，防止一直傻傻等待傻傻的問。會根據最近自旋的成功率、失敗率。
如果最近嘗試自旋獲取某一把鎖成功了，那么下一次可能還會繼續使用自旋，并且允許自旋更長的時間；但是如果最近自旋獲取某一把鎖失敗了，那么可能會省略掉自旋的過程，以便減少無用的自旋，提高效率。
鎖消除
淑妃詭詐，在公元 107 年一個夜黑風高的夜晚，串通后廚小哲子放了無色無味的黯然銷魂藥，一個個有氣無力。
所以只剩下自己一個人向 synchronized 大總管申請，便不需要繁瑣流程，直搗黃龍。直接面見老王，無需加鎖。
鎖消除即刪除不必要的加鎖操作。虛擬機即時編輯器在運行時，對一些“代碼上要求同步，但是被檢測到不可能存在共享數據競爭”的鎖進行消除。
根據代碼逃逸技術，如果判斷到一段代碼中，堆上的數據不會逃逸出當前線程，那么可以認為這段代碼是線程安全的，不必要加鎖。
public?class?SynchronizedTest?{public?static?void?main(String[]?args)?{SynchronizedTest?test?=?new?SynchronizedTest();for?(int?i?=?0;?i?<?100000000;?i++)?{test.append("AAA",?"def");}}public?void?append(String?str1,?String?str2)?{StringBuffer?sb?=?new?StringBuffer();sb.append(str1).append(str2);} }雖然StringBuffer的append是一個同步方法，但是這段程序中的StringBuffer屬于一個局部變量，并且不會從該方法中逃逸出去（即StringBuffer sb的引用沒有傳遞到該方法外，不可能被其他線程拿到該引用），所以其實這過程是線程安全的，可以將鎖消除。
鎖粗化
甄嬛深得老王寵愛，被偏愛的都有恃無恐。每次進出 synchronized 大總管張掛你的大門都需要驗證是否獲得 monitor 鎖，甄嬛進來后還喜歡出去外面走走過一會有進來看幾眼老王又出去，大總管也不用每次都要驗證，將限制的范圍就加大了，防止反復驗證。
如果一系列的連續操作都對同一個對象反復加鎖和解鎖，甚至加鎖操作是出現在循環體中的，那即使沒有出現線程競爭，頻繁地進行互斥同步操作也會導致不必要的性能損耗。
如果虛擬機檢測到有一串零碎的操作都是對同一對象的加鎖，將會把加鎖同步的范圍擴展（粗化）到整個操作序列的外部。
public?class?StringBufferTest?{StringBuffer?stringBuffer?=?new?StringBuffer();public?void?append(){stringBuffer.append("關注");stringBuffer.append("公眾號");stringBuffer.append("AAA");} }每次調用stringBuffer.append方法都需要加鎖和解鎖，如果虛擬機檢測到有一系列連串的對同一個對象加鎖和解鎖操作，就會將其合并成一次范圍更大的加鎖和解鎖操作，即在第一次 append 方法時進行加鎖，最后一次 append 方法結束后進行解鎖。
偏向鎖/輕量級鎖/重量級鎖
本文主要講解針對 synchronized 性能低 JVM 所做的優化手段。
偏向鎖
老王偏愛甄嬛，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，關閉之后程序默認會進入輕量級鎖狀態。
輕量級鎖
是指當鎖是偏向鎖的時候，被另外的線程所訪問，偏向鎖就會升級為輕量級鎖，其他線程會通過自旋的形式嘗試獲取鎖，不會阻塞，從而提高性能。
在代碼進入同步塊的時候，如果同步對象鎖狀態為無鎖狀態（鎖標志位為“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中存儲的就是指向重量級鎖（互斥量）的指針，后面等待鎖的線程也要進入阻塞狀態。
重量級鎖
如上輕量級鎖的加鎖過程步驟（5），輕量級鎖所適應的場景是線程近乎交替執行同步塊的情況，如果存在同一時間訪問同一鎖的情況，就會導致輕量級鎖膨脹為重量級鎖。Mark Word的鎖標記位更新為10，Mark Word指向互斥量（重量級鎖）
Synchronized 的重量級鎖是通過對象內部的一個叫做監視器鎖（monitor）來實現的，監視器鎖本質又是依賴于底層的操作系統的 Mutex Lock（互斥鎖）來實現的。而操作系統實現線程之間的切換需要從用戶態轉換到核心態，這個成本非常高，狀態之間的轉換需要相對比較長的時間，這就是為什么 Synchronized 效率低的原因。
鎖升級路徑
從無鎖到偏向鎖，再到輕量級鎖，最后到重量級鎖。結合前面我們講過的知識，偏向鎖性能最好，避免了 CAS 操作。而輕量級鎖利用自旋和 CAS 避免了重量級鎖帶來的線程阻塞和喚醒，性能中等。重量級鎖則會把獲取不到鎖的線程阻塞，性能最差。
鎖升級綜上，偏向鎖通過對比 Mark Word 解決加鎖問題，避免執行CAS操作。而輕量級鎖是通過用CAS操作和自旋來解決加鎖問題，避免線程阻塞和喚醒而影響性能。重量級鎖是將除了擁有鎖的線程以外的線程都阻塞。
鳴謝
Java synchronized原理總結: https://zhuanlan.zhihu.com/p/29866981
不可不說的Java“鎖”事: https://tech.meituan.com/2018/11/15/java-lock.html
有道無術，術可成；有術無道，止于術
歡迎大家關注Java之道公眾號
好文章，我在看??
總結
以上是生活随笔為你收集整理的synchronized 王的后宫总管，线程是王妃的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 0322 第一天 心得体会
- 下一篇： 看 B 站，可以更快！