由淺入深逐步了解 Synchronized
本文轉(zhuǎn)載自微信公眾號「sowhat1412」，作者sowhat1412。轉(zhuǎn)載本文請聯(lián)系sowhat1412公眾號。
使用
synchronized關(guān)鍵字是Java并發(fā)編程中線程同步的常用手段之一，其作用有三個:
- 互斥性：確保線程互斥的訪問同步代，鎖自動釋放，多個線程操作同個代碼塊或函數(shù)必須排隊獲得鎖，
- 可見性：保證共享變量的修改能夠及時可見，獲得鎖的線程操作完畢后會將所數(shù)據(jù)刷新到共享內(nèi)存區(qū)[1]
- 有序性：有效解決重排序問題
synchronized用法有三個:
- 修飾實例方法
- 修飾靜態(tài)方法
- 修飾代碼塊
1. 修飾實例方法
synchronized關(guān)鍵詞作用在方法的前面，用來鎖定方法，其實默認鎖定的是this對象。
- public class Thread1 implements Runnable{
- //共享資源(臨界資源)
- static int i=0;
- //如果沒有synchronized關(guān)鍵字，輸出小于20000
- public synchronized void increase(){
- i++;
- }
- public void run() {
- for(int j=0;j<10000;j++){
- increase();
- }
- }
- public static void main(String[] args) throws InterruptedException {
- Thread1 t=new Thread1();
- Thread t1=new Thread(t);
- Thread t2=new Thread(t);
- t1.start();
- t2.start();
- t1.join();//主線程等待t1執(zhí)行完畢
- t2.join();//主線程等待t2執(zhí)行完畢
- System.out.println(i);
- }
- }
2. 修飾靜態(tài)方法
synchronized還是修飾在方法上，不過修飾的是靜態(tài)方法，等價于鎖定的是Class對象，
- public class Thread1 {
- //共享資源(臨界資源)
- static int i = 0;
- //如果沒有synchronized關(guān)鍵字，輸出小于20000
- public static synchronized void increase() {
- i++;
- }
- public static void main(String[] args) throws InterruptedException {
- Thread t1 = new Thread(new Runnable() {
- public void run() {
- for (int j = 0; j < 10000; j++) {
- increase();
- }
- }
- });
- Thread t2 = new Thread(new Runnable() {
- @Override
- public void run() {
- for (int j = 0; j < 10000; j++) {
- increase();
- }
- }
- });
- t1.start();
- t2.start();
- t1.join();//主線程等待t1執(zhí)行完畢
- t2.join();//主線程等待t2執(zhí)行完畢
- System.out.println(i);
- }
3. 修飾代碼塊
用法是在函數(shù)體內(nèi)部對于要修改的參數(shù)區(qū)間用synchronized來修飾，相比與鎖定函數(shù)這個范圍更小，可以指定鎖定什么對象。
- public class Thread1 implements Runnable {
- //共享資源(臨界資源)
- static int i = 0;
- @Override
- public void run() {
- for (int j = 0; j < 10000; j++) {
- //獲得了String的類鎖
- synchronized (String.class) {
- i++;
- }
- }
- }
- public static void main(String[] args) throws InterruptedException {
- Thread1 t = new Thread1();
- Thread t1 = new Thread(t);
- Thread t2 = new Thread(t);
- t1.start();
- t2.start();
- t1.join();
- t2.join();
- System.out.println(i);
- }
- }
總結(jié)：
- synchronized修飾的實例方法，多線程并發(fā)訪問時，只能有一個線程進入，獲得對象內(nèi)置鎖，其他線程阻塞等待，但在此期間線程仍然可以訪問其他方法。
- synchronized修飾的靜態(tài)方法，多線程并發(fā)訪問時，只能有一個線程進入，獲得類鎖，其他線程阻塞等待，但在此期間線程仍然可以訪問其他方法。
- synchronized修飾的代碼塊，多線程并發(fā)訪問時，只能有一個線程進入，根據(jù)括號中的對象或者是類，獲得相應(yīng)的對象內(nèi)置鎖或者是類鎖
- 每個類都有一個類鎖，類的每個對象也有一個內(nèi)置鎖，它們是互不干擾的，也就是說一個線程可以同時獲得類鎖和該類實例化對象的內(nèi)置鎖，當(dāng)線程訪問非synchronzied修飾的方法時，并不需要獲得鎖，因此不會產(chǎn)生阻塞。
管程
管程[2] (英語：Monitors，也稱為監(jiān)視器) 在操作系統(tǒng)中是很重要的概念，管程其實指的是管理共享變量以及管理共享變量的操作過程。有點扮演中介的意思，管程管理一堆對象，多個線程同一時候只能有一個線程來訪問這些東西。
- 管程可以看做一個軟件模塊，它是將共享的變量和對于這些共享變量的操作封裝起來，形成一個具有一定接口的功能模塊，進程可以調(diào)用管程來實現(xiàn)進程級別的并發(fā)控制。
- 進程只能互斥的使用管程，即當(dāng)一個進程使用管程時，另一個進程必須等待。當(dāng)一個進程使用完管程后，它必須釋放管程并喚醒等待管程的某一個進程。
管程解決互斥問題相對簡單，把共享變量以及共享變量的操作都封裝在一個類中
當(dāng)線程A和線程B需要獲取共享變量count時，就需要調(diào)用get和set方法，而get和set方法則保證互斥性，保證每次只能有一個線程訪問。
生活中舉例管程比如鏈家店長分配給每一個中介管理一部分二手房源，多個客戶通過中介進行房屋買賣。
- 中介 就是管程。
- 多個二手房源被一個中介管理中，就是一個管程管理著多個系統(tǒng)資源。
- 多個客戶就相當(dāng)于多個線程。
Synchronzied的底層原理
對象頭解析
我們知道在Java的JVM內(nèi)存區(qū)域[3]中一個對象在堆區(qū)創(chuàng)建，創(chuàng)建后的對象由三部分組成。
這三部分功能如下：
- 填充數(shù)據(jù)：由于虛擬機要求對象起始地址必須是8字節(jié)的整數(shù)倍。填充數(shù)據(jù)不是必須存在的，僅僅是為了字節(jié)對齊。
- 實例變量：存放類的屬性數(shù)據(jù)信息，包括父類的屬性信息，這部分內(nèi)存按4字節(jié)對齊。
- 對象頭：主要包括兩部分 Klass Point跟 Mark Word
Klass Point(類型指針)：是對象指向它的類元數(shù)據(jù)的指針，虛擬機通過這個指針來確定這個對象是哪個類的實例。
Mark Word(標(biāo)記字段)：這一部分用于儲存對象自身的運行時數(shù)據(jù)，如哈希碼，GC分代年齡，鎖狀態(tài)標(biāo)志，鎖指針等，這部分數(shù)據(jù)在32bit和64bit的虛擬機中大小分別為32bit和64bit，考慮到虛擬機的空間效率，Mark Word被設(shè)計成一個非固定的數(shù)據(jù)結(jié)構(gòu)以便在極小的空間中存儲盡量多的信息，它會根據(jù)對象的狀態(tài)復(fù)用自己的存儲空間(跟ConcurrentHashMap里的標(biāo)志位類似)，詳細情況如下圖：
Mark Word狀態(tài)表示位如下：
synchronized不論是修飾方法還是代碼塊，都是通過持有修飾對象的鎖來實現(xiàn)同步，synchronized鎖對象是存在對象頭Mark Word。其中輕量級鎖和偏向鎖是Java6對synchronized鎖進行優(yōu)化后新增加的，這里我們主要分析一下重量級鎖也就是通常說synchronized的對象鎖，鎖標(biāo)識位為10，其中指針指向的是monitor對象(也稱為管程或監(jiān)視器鎖)的起始地址。每個對象都存在著一個 monitor[4] 與之關(guān)聯(lián)。
反匯編查看
分析對象的monitor前我們先通過反匯編看下同步方法跟同步方法塊在匯編語言級別是什么樣的指令。
- public class SynchronizedTest {
- public synchronized void doSth(){
- System.out.println("Hello World");
- }
- public void doSth1(){
- synchronized (SynchronizedTest.class){
- System.out.println("Hello World");
- }
- }
- }
javac SynchronizedTest .java 然后javap -c SynchronizedTest反編譯后看匯編指令如下：
- public synchronized void doSth();
- descriptor: ()V
- flags: ACC_PUBLIC, ACC_SYNCHRONIZED // 這是重點 方法鎖
- Code:
- stack=2, locals=1, args_size=1
- 0: getstatic #2
- 3: ldc #3
- 5: invokevirtual #4
- 8: return
- public void doSth1();
- descriptor: ()V
- flags: ACC_PUBLIC
- Code:
- stack=2, locals=3, args_size=1
- 0: ldc #5
- 2: dup
- 3: astore_1
- 4: monitorenter // 進入同步方法
- 5: getstatic #2
- 8: ldc #3
- 10: invokevirtual #4
- 13: aload_1
- 14: monitorexit //正常時 退出同步方法
- 15: goto 23
- 18: astore_2
- 19: aload_1
- 20: monitorexit // 異常時 退出同步方法
- 21: aload_2
- 22: athrow
- 23: return
我們可以看到Java編譯器為我們生成的字節(jié)碼。在對于doSth和doSth1的處理上稍有不同。也就是說。JVM對于同步方法和同步代碼塊的處理方式不同。對于同步方法，JVM采用ACC_SYNCHRONIZED標(biāo)記符來實現(xiàn)同步。對于同步代碼塊。JVM采用monitorenter、monitorexit兩個指令來實現(xiàn)同步。
- ACC_SYNCHRONIZED
方法級的同步是隱式的。同步方法的常量池中會有一個ACC_SYNCHRONIZED標(biāo)志。當(dāng)某個線程要訪問某個方法的時候，會檢查是否有ACC_SYNCHRONIZED，如果有設(shè)置，則需要先獲得監(jiān)視器鎖，然后開始執(zhí)行方法，方法執(zhí)行之后再釋放監(jiān)視器鎖。這時如果其他線程來請求執(zhí)行方法，會因為無法獲得監(jiān)視器鎖而被阻斷住。值得注意的是，如果在方法執(zhí)行過程中，發(fā)生了異常，并且方法內(nèi)部并沒有處理該異常，那么在異常被拋到方法外面之前監(jiān)視器鎖會被自動釋放。
- monitorenter跟monitorexit
可以把執(zhí)行monitorenter指令理解為加鎖，執(zhí)行monitorexit理解為釋放鎖。每個對象維護著一個記錄著被鎖次數(shù)的計數(shù)器。未被鎖定的對象的該計數(shù)器為0，當(dāng)一個線程獲得鎖(執(zhí)行monitorenter)后，該計數(shù)器自增變?yōu)? 1 ，當(dāng)同一個線程再次獲得該對象的鎖的時候，計數(shù)器再次自增。當(dāng)同一個線程釋放鎖(執(zhí)行monitorexit指令)的時候，計數(shù)器再自減。當(dāng)計數(shù)器為0的時候。鎖將被釋放，其他線程便可以獲得鎖。
結(jié)論：同步方法和同步代碼塊底層都是通過monitor來實現(xiàn)同步的。兩者區(qū)別：同步方式是通過方法中的access_flags中設(shè)置ACC_SYNCHRONIZED標(biāo)志來實現(xiàn)，同步代碼塊是通過monitorenter和monitorexit來實現(xiàn)。
monitor解析
每個對象都與一個monitor相關(guān)聯(lián)，而monitor可以被線程擁有或釋放，在Java虛擬機(HotSpot)中，monitor是由ObjectMonitor實現(xiàn)的，其主要數(shù)據(jù)結(jié)構(gòu)如下(位于HotSpot虛擬機源碼ObjectMonitor.hpp文件，C++實現(xiàn)的)。
- ObjectMonitor() {
- _count = 0; //記錄數(shù)
- _recursions = 0; //鎖的重入次數(shù)
- _owner = NULL; //指向持有ObjectMonitor對象的線程
- _WaitSet = NULL; //調(diào)用wait后，線程會被加入到_WaitSet
- _EntryList = NULL ; //等待獲取鎖的線程，會被加入到該列表
- }
monitor運行圖如下：
對于一個synchronized修飾的方法(代碼塊)來說：
- 當(dāng)多個線程同時訪問該方法，那么這些線程會先被放進_EntryList隊列，此時線程處于blocked狀態(tài)
- 當(dāng)一個線程獲取到了對象的monitor后，那么就可以進入running狀態(tài)，執(zhí)行方法塊，此時，ObjectMonitor對象的_owner指向當(dāng)前線程，_count加1表示當(dāng)前對象鎖被一個線程獲取。
- 當(dāng)running狀態(tài)的線程調(diào)用wait()方法，那么當(dāng)前線程釋放monitor對象，進入waiting狀態(tài)，ObjectMonitor對象的_owner變?yōu)閚ull，_count減1，同時線程進入_WaitSet隊列，直到有線程調(diào)用notify()方法喚醒該線程，則該線程進入_EntryList隊列，競爭到鎖再進入_owner區(qū)。
- 如果當(dāng)前線程執(zhí)行完畢，那么也釋放monitor對象，ObjectMonitor對象的_owner變?yōu)閚ull，_count減1。
因為監(jiān)視器鎖(monitor)是依賴于底層的操作系統(tǒng)的Mutex Lock來實現(xiàn)的，而操作系統(tǒng)實現(xiàn)線程之間的切換時需要從用戶態(tài)轉(zhuǎn)換到核心態(tài)(具體可看CXUAN寫的OS哦)，這個狀態(tài)之間的轉(zhuǎn)換需要相對比較長的時間，時間成本相對較高，這也是早期的synchronized效率低的原因。慶幸在Java 6之后Java官方對從JVM層面對synchronized較大優(yōu)化最終提升顯著，Java 6之后，為了減少獲得鎖和釋放鎖所帶來的性能消耗，引入了鎖升級的概念。
鎖升級
synchronized鎖有四種狀態(tài)，無鎖、偏向鎖、輕量級鎖、重量級鎖。這幾個狀態(tài)會隨著競爭狀態(tài)逐漸升級，鎖可以升級但不能降級，但是偏向鎖狀態(tài)可以被重置為無鎖狀態(tài)。科學(xué)性的說這些鎖之前我們先看個簡單通俗的例子來加深印象。
通俗說各種鎖
偏向鎖、輕量級鎖和重量級鎖之間的關(guān)系，首先打個比方[5]：假設(shè)現(xiàn)在廁所只有一個位置，每個使用者都有打開門鎖的鑰匙。必須打開門鎖才能使用廁所。其中小明、小紅理解為兩個線程，上廁所理解為執(zhí)行同步代碼，門鎖理解為同步代碼的鎖
- 小明今天吃壞了東西需要反復(fù)去廁所，如果小明每次都要開鎖就很耽誤時間，于是門鎖將小明的臉記錄下來(假設(shè)那個鎖是智能鎖)，下次小明再來的時候門鎖會自動識別出是小明來了，然后自動開鎖，這樣就省去了小明拿鑰匙開門的過程，此時門鎖就是偏向鎖，也可以理解為偏向小明的鎖。
- 接下來，小紅又去上廁所，試圖將廁所的門鎖設(shè)置為偏向自己的偏向鎖，于是發(fā)現(xiàn)門鎖無法偏向自己，因為此時門鎖已是偏向小明的偏向鎖。于是小紅很生氣，要求門鎖撤銷對小明的偏向，當(dāng)然，小明也不同意門鎖偏向小紅。于是等小明用完廁所之后，門鎖撤銷了對任何人的偏向(只要出現(xiàn)競爭的情況，就會撤銷偏向鎖)。這個過程就是撤銷偏向鎖。此時門鎖升級為輕量級鎖。
- 等小明出來以后，輕量級鎖正式生效 。下一次小明和小紅同時來廁所，誰跑的快誰先走到門前，開門后將門鎖拿進廁所，并將門鎖打開以后拿進廁所里，將門反鎖，于是在門外原來放門鎖的位置放置了一個有人的標(biāo)志(這個標(biāo)識可以理解為指向門鎖的指針，或者理解為作為鎖的Java對象頭的Mark Word值)，這時，小紅看到有人以后很著急，催著里面的人出來時馬上進去，于是不斷的來敲門，問小明什么時候出來。這個過程就是自旋。
- 反復(fù)敲了幾次以后，小明受不了了，對小紅喊話，說你別敲了，等我用完廁所我告訴你，于是小紅去一邊等著(線性阻塞)。此時門鎖升級為重量級鎖。升級為重量級鎖的后果就是，小紅不再反復(fù)敲門，小明在上完廁所以后必須告訴小紅一聲，否則小紅就會一直等著。
結(jié)論：
偏向鎖在只有一個人上廁所時非常高效，省去了開門的過程。輕量級鎖在有多人上廁所但是每個人使用的特別快的時候，比較高效，因為會出現(xiàn)這種現(xiàn)象，小紅敲門的時候正好趕上小明出來，這樣就省得小明出來告訴小紅以后小紅才能進去，但是這樣可能會出現(xiàn)小紅敲門失敗的情況(就是敲門時小明還沒用完)。重量級鎖相比與輕量級鎖的多了一步小明呼喚小紅的步驟，但是卻省掉了小紅反復(fù)去敲門的過程，但是能保證小紅去廁所時廁所一定是沒人的。
偏向鎖
經(jīng)過HotSpot的作者大量的研究發(fā)現(xiàn)大多數(shù)時候是不存在鎖競爭的，經(jīng)常是一個線程多次獲得同一個鎖，因此如果每次都要競爭鎖會增大很多沒有必要付出的代價，為了降低獲取鎖的代價，才引入的偏向鎖。核心思想：
如果一個線程獲得了鎖，那么鎖就進入偏向模式，此時Mark Word 的結(jié)構(gòu)也變?yōu)槠蜴i結(jié)構(gòu)，當(dāng)這個線程再次請求鎖時，無需再做任何同步操作，即獲取鎖的過程，這樣就省去了大量有關(guān)鎖申請的操作，從而也就提供程序的性能。所以，對于沒有鎖競爭的場合，偏向鎖有很好的優(yōu)化效果，畢竟極有可能連續(xù)多次是同一個線程申請相同的鎖。但是對于鎖競爭比較激烈的場合，偏向鎖就失效了，因為這樣場合極有可能每次申請鎖的線程都是不相同的，因此這種場合下不應(yīng)該使用偏向鎖，否則會得不償失，需要注意的是，偏向鎖失敗后，并不會立即膨脹為重量級鎖，而是先升級為輕量級鎖。
具體流程：當(dāng)線程1訪問代碼塊并獲取鎖對象時，會在java對象頭和棧幀中記錄偏向的鎖的threadID，因為偏向鎖不會主動釋放鎖，因此以后線程1再次獲取鎖的時候，需要比較當(dāng)前線程的threadID和Java對象頭中的threadID是否一致，如果一致(還是線程1獲取鎖對象)，則無需使用CAS來加鎖、解鎖;如果不一致(其他線程，如線程2要競爭鎖對象，而偏向鎖不會主動釋放因此還是存儲的線程1的threadID)，那么需要查看Java對象頭中記錄的線程1是否存活，如果沒有存活，那么鎖對象被重置為無鎖狀態(tài)，其它線程(線程2)可以競爭將其設(shè)置為偏向鎖;如果存活，那么立刻查找該線程(線程1)的棧幀信息，如果還是需要繼續(xù)持有這個鎖對象，那么暫停當(dāng)前線程1，撤銷偏向鎖，升級為 輕量級鎖，如果線程1不再使用該鎖對象，那么將鎖對象狀態(tài)設(shè)為無鎖狀態(tài)，重新偏向新的線程。
輕量級鎖
輕量級鎖考慮的是競爭鎖對象的線程不多，而且線程持有鎖的時間也不長的情景。因為阻塞線程需要高昂的耗時實現(xiàn)CPU從用戶態(tài)轉(zhuǎn)到內(nèi)核態(tài)的切換，如果剛剛阻塞不久這個鎖就被釋放了，那這個代價就有點得不償失了，因此這個時候就干脆不阻塞這個線程，讓它自旋這等待鎖釋放。
「原理跟升級」：線程1獲取輕量級鎖時會先把鎖對象的對象頭MarkWord復(fù)制一份到線程1的棧幀中創(chuàng)建的用于存儲鎖記錄的空間(稱為DisplacedMarkWord)，然后使用CAS把對象頭中的內(nèi)容替換為線程1存儲的鎖記錄(DisplacedMarkWord)的地址;
如果在線程1復(fù)制對象頭的同時(在線程1CAS之前)，線程2也準備獲取鎖，復(fù)制了對象頭到線程2的鎖記錄空間中，但是在線程2CAS的時候，發(fā)現(xiàn)線程1已經(jīng)把對象頭換了，「線程2的CAS失敗，那么線程2就嘗試使用自旋鎖來等待線程1釋放鎖」。自旋鎖簡單來說就是讓線程2在循環(huán)中不斷CAS嘗試獲得鎖對象。
但是如果自旋的「時間太長」也不行，因為自旋是要消耗CPU的，因此「自旋的次數(shù)是有限制」的，比如10次或者100次，如果自旋次數(shù)到了線程1還沒有釋放鎖，或者線程1還在執(zhí)行，線程2還在自旋等待，那么這個時候輕量級鎖就會膨脹為重量級鎖。重量級鎖把除了擁有鎖的線程都阻塞，防止CPU空轉(zhuǎn)。
鎖消除
消除鎖是虛擬機另外一種鎖的優(yōu)化，這種優(yōu)化更徹底，Java虛擬機在JIT編譯時通過對運行上下文的掃描，去除不可能存在共享資源競爭的鎖，通過這種方式消，除沒有必要的鎖，可以節(jié)省毫無意義的請求鎖時間，我們知道StringBuffer是線程安全的，里面包含鎖的存在，但是如果我們在函數(shù)內(nèi)部使用StringBuffer那么代碼會在JIT后會自動將鎖釋放掉哦。
對比如下：
| 鎖狀態(tài) | 優(yōu)點 | 缺點 | 適用場景 |
|---|---|---|---|
| 偏向鎖 | 加鎖解鎖無需額外消耗，跟非同步方法時間相差納秒級別 | 如果競爭線程多，會帶來額外的鎖撤銷的消耗 | 基本沒有其他線程競爭的同步場景 |
| 輕量級鎖 | 競爭的線程不會阻塞而是在自旋，可提高程序響應(yīng)速度 | 如果一直無法獲得會自旋消耗CPU | 少量線程競爭，持有鎖時間不長，追求響應(yīng)速度 |
| 重量級鎖 | 線程競爭不會導(dǎo)致CPU自旋跟消耗CPU資源 | 線程阻塞，響應(yīng)時間長 | 很多線程競爭鎖，切鎖持有時間長，追求吞吐量時候 |
PS：ReentrantLock底層實現(xiàn)依賴于特殊的CPU指令，比如發(fā)送lock指令和unlock指令，不需要用戶態(tài)和內(nèi)核態(tài)的切換，所以效率高。而synchronized底層由監(jiān)視器鎖(monitor)是依賴于底層的操作系統(tǒng)的Mutex Lock需要用戶態(tài)和內(nèi)核態(tài)的切換，所以效率會低一些。
Reference
[1]管程:
https://www.zhihu.com/question/30641734
[2]monitor:
http://www.hollischuang.com/archives/2030
[3]比方:
https://blog.csdn.net/xyh930929/article/details/84571805
[4]unbelievableme:
https://www.cnblogs.com/kundeg/p/8422557.html
[5]頭條大佬講syn:
https://blog.csdn.net/javazejian/article/details/72828483
[6]阿里hollis將syn:
http://www.hollischuang.com/archives/2030
