<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          synchronized 優(yōu)化手段之鎖膨脹機(jī)制!

          共 3684字,需瀏覽 8分鐘

           ·

          2021-08-07 01:43

          作者 | 王磊

          來(lái)源 | Java中文社群(ID:javacn666)

          轉(zhuǎn)載請(qǐng)聯(lián)系授權(quán)(微信ID:GG_Stone)

          synchronized 在 JDK 1.5 之前性能是比較低的,在那時(shí)我們通常會(huì)選擇使用 Lock 來(lái)替代 synchronized。然而這個(gè)情況在 JDK 1.6 時(shí)就發(fā)生了改變,JDK 1.6 中對(duì) synchronized 進(jìn)行了各種優(yōu)化,性能也得到了大幅的提升,這也是目前版本中還能經(jīng)常見(jiàn)到 synchronized 身影的重要原因之一。當(dāng)然除了性能之外,synchronized 的使用也非常便利,這也是它流行的重要原因。

          在眾多優(yōu)化方案中,鎖膨脹機(jī)制是提升 synchronized 性能最有利的手段之一(其他優(yōu)化方案我們后面再講),本文我們重點(diǎn)來(lái)看什么是鎖膨脹?以及鎖膨脹的各種細(xì)節(jié)。

          正文

          在 JDK 1.5 時(shí),synchronized 需要調(diào)用監(jiān)視器鎖(Monitor)來(lái)實(shí)現(xiàn),監(jiān)視器鎖本質(zhì)上又是依賴于底層的操作系統(tǒng)的 Mutex Lock(互斥鎖)實(shí)現(xiàn)的,互斥鎖在進(jìn)行釋放和獲取的時(shí)候,需要從用戶態(tài)轉(zhuǎn)換到內(nèi)核態(tài),這樣就造成了很高的成本,也需要較長(zhǎng)的執(zhí)行時(shí)間,這種依賴于操作系統(tǒng) Mutex Lock 實(shí)現(xiàn)的鎖我們稱之為“重量級(jí)鎖”。

          什么是用戶態(tài)和內(nèi)核態(tài)?

          用戶態(tài)(User Mode):當(dāng)進(jìn)程在執(zhí)行用戶自己的代碼時(shí),則稱其處于用戶運(yùn)行態(tài)。內(nèi)核態(tài)(Kernel Mode):當(dāng)一個(gè)任務(wù)(進(jìn)程)執(zhí)行系統(tǒng)調(diào)用而陷入內(nèi)核代碼中執(zhí)行時(shí),我們就稱進(jìn)程處于內(nèi)核運(yùn)行態(tài),此時(shí)處理器處于特權(quán)級(jí)最高的內(nèi)核代碼中執(zhí)行。

          為什么分內(nèi)核態(tài)和用戶態(tài)?

          假設(shè)沒(méi)有內(nèi)核態(tài)和用戶態(tài)之分,程序就可以隨意讀寫(xiě)硬件資源了,比如隨意讀寫(xiě)和分配內(nèi)存,這樣如果程序員一不小心將不適當(dāng)?shù)膬?nèi)容寫(xiě)到了不該寫(xiě)的地方,很可能就會(huì)導(dǎo)致系統(tǒng)崩潰。

          而有了用戶態(tài)和內(nèi)核態(tài)的區(qū)分之后,程序在執(zhí)行某個(gè)操作時(shí)會(huì)進(jìn)行一系列的驗(yàn)證和檢驗(yàn)之后,確認(rèn)沒(méi)問(wèn)題之后才可以正常的操作資源,這樣就不會(huì)擔(dān)心一不小心就把系統(tǒng)搞壞的情況了,也就是有了內(nèi)核態(tài)和用戶態(tài)的區(qū)分之后可以讓程序更加安全的運(yùn)行,但同時(shí)兩種形態(tài)的切換會(huì)導(dǎo)致一定的性能開(kāi)銷。

          鎖膨脹

          在 JDK 1.6 時(shí),為了解決獲取鎖和釋放鎖帶來(lái)的性能消耗,引入了“偏向鎖”和“輕量級(jí)鎖”的狀態(tài),此時(shí) synchronized 的狀態(tài)總共有以下 4 種:

          1. 無(wú)鎖
          2. 偏向鎖
          3. 輕量級(jí)鎖
          4. 重量級(jí)鎖

          鎖的級(jí)別按照上述先后順序依次升級(jí),我們把這個(gè)升級(jí)的過(guò)程稱之為“鎖膨脹”。

          PS:到現(xiàn)在為止,鎖的升級(jí)是單向的,也就是說(shuō)只能從低到高升級(jí)(無(wú)鎖 -> 偏向鎖 -> 輕量鎖鎖 -> 重量級(jí)鎖),不會(huì)出現(xiàn)鎖降級(jí)的情況。

          鎖膨脹為什么能優(yōu)化 synchronized 的性能?當(dāng)我們了解了這些鎖狀態(tài)之后自然就會(huì)有答案,下面我們一起來(lái)看。

          1.偏向鎖

          HotSpot 作者經(jīng)過(guò)研究實(shí)踐發(fā)現(xiàn),在大多數(shù)情況下,鎖不存在多線程競(jìng)爭(zhēng),總是由同一線程多次獲得的,為了讓線程獲得鎖的代價(jià)更低,于是就引進(jìn)了偏向鎖。

          偏向鎖(Biased Locking)指的是,它會(huì)偏向于第一個(gè)訪問(wèn)鎖的線程,如果在運(yùn)行過(guò)程中,同步鎖只有一個(gè)線程訪問(wèn),不存在多線程爭(zhēng)用的情況,則線程是不需要觸發(fā)同步的,這種情況下會(huì)給線程加一個(gè)偏向鎖。

          偏向鎖執(zhí)行流程

          當(dāng)一個(gè)線程訪問(wèn)同步代碼塊并獲取鎖時(shí),會(huì)在對(duì)象頭的 Mark Word 里存儲(chǔ)鎖偏向的線程 ID,在線程進(jìn)入和退出同步塊時(shí)不再通過(guò) CAS 操作來(lái)加鎖和解鎖,而是檢測(cè) Mark Word 里是否存儲(chǔ)著指向當(dāng)前線程的偏向鎖,如果 Mark Word 中的線程 ID 和訪問(wèn)的線程 ID 一致,則可以直接進(jìn)入同步塊進(jìn)行代碼執(zhí)行,如果線程 ID 不同,則使用 CAS 嘗試獲取鎖,如果獲取成功則進(jìn)入同步塊執(zhí)行代碼,否則會(huì)將鎖的狀態(tài)升級(jí)為輕量級(jí)鎖。

          偏向鎖的優(yōu)點(diǎn)

          偏向鎖是為了在無(wú)多線程競(jìng)爭(zhēng)的情況下,盡量減少不必要的鎖切換而設(shè)計(jì)的,因?yàn)殒i的獲取及釋放要依賴多次 CAS 原子指令,而偏向鎖只需要在置換線程 ID 的時(shí)候執(zhí)行一次 CAS 原子指令即可。

          Mark Word 擴(kuò)展知識(shí):內(nèi)存布局

          在 HotSpot 虛擬機(jī)中,對(duì)象在內(nèi)存中存儲(chǔ)的布局可以分為以下 3 個(gè)區(qū)域:

          1. 對(duì)象頭(Header)
          2. 實(shí)例數(shù)據(jù)(Instance Data)
          3. 對(duì)齊填充(Padding)

          對(duì)象頭中又包含了:

          1. Mark Word(標(biāo)記字段):我們的偏向鎖信息就是存儲(chǔ)在此區(qū)域的
          2. Klass Pointer(Class 對(duì)象指針)

          對(duì)象在內(nèi)存中的布局如下:在 JDK 1.6 中默認(rèn)是開(kāi)啟偏向鎖的,可以通過(guò)“-XX:-UseBiasedLocking=false”命令來(lái)禁用偏向鎖。

          2.輕量級(jí)鎖

          引入輕量級(jí)鎖的目的是在沒(méi)有多線程競(jìng)爭(zhēng)的前提下,減少傳統(tǒng)的重量級(jí)鎖使用操作系統(tǒng) Mutex Lock(互斥鎖)產(chǎn)生的性能消耗。如果使用 Mutex Lock 每次獲取鎖和釋放鎖的操作都會(huì)帶來(lái)用戶態(tài)和內(nèi)核態(tài)的切換,這樣系統(tǒng)的性能開(kāi)銷是很大的。

          當(dāng)關(guān)閉偏向鎖或者多個(gè)線程競(jìng)爭(zhēng)偏向鎖時(shí)就會(huì)導(dǎo)致偏向鎖升級(jí)為輕量級(jí)鎖,輕量級(jí)鎖的獲取和釋放都通過(guò) CAS 完成的,其中鎖獲取可能會(huì)通過(guò)一定次數(shù)的自旋來(lái)完成。

          注意事項(xiàng)

          需要強(qiáng)調(diào)一點(diǎn):輕量級(jí)鎖并不是用來(lái)代替重量級(jí)鎖的,它的本意是在沒(méi)有多線程競(jìng)爭(zhēng)的前提下,減少傳統(tǒng)的重量級(jí)鎖使用產(chǎn)生的性能消耗。輕量級(jí)鎖所適應(yīng)的場(chǎng)景是線程交替執(zhí)行同步塊的情況,如果同一時(shí)間多個(gè)線程同時(shí)訪問(wèn)時(shí),就會(huì)導(dǎo)致輕量級(jí)鎖膨脹為重量級(jí)鎖。

          3.重量級(jí)鎖

          synchronized 是依賴監(jiān)視器 Monitor 實(shí)現(xiàn)方法同步或代碼塊同步的,代碼塊同步使用的是 monitorenter 和 monitorexit 指令來(lái)實(shí)現(xiàn)的,monitorenter 指令是在編譯后插入到同步代碼塊的開(kāi)始位置,而 monitorexit 是插入到方法結(jié)束處和異常處的,任何對(duì)象都有一個(gè) Monitor 與之關(guān)聯(lián),當(dāng)且一個(gè) Monitor 被持有后,它將處于鎖定狀態(tài)。

          如以下加鎖代碼:

          public class SynchronizedToMonitorExample {
          public static void main(String[] args) {
          int count = 0;
          synchronized (SynchronizedToMonitorExample.class) {
          for (int i = 0; i < 10; i++) {
          count++;
          }
          }
          System.out.println(count);
          }
          }

          當(dāng)我們將上述代碼編譯成字節(jié)碼之后,它的內(nèi)容是這樣的:


          從上述結(jié)果可以看出,在 main 方法的執(zhí)行中多個(gè) monitorenter 和 monitorexit 的指令,由此可知 synchronized 是依賴 Monitor 監(jiān)視器鎖實(shí)現(xiàn)的,而監(jiān)視器鎖又是依賴操作系統(tǒng)的互斥鎖(Mutex Lock),互斥鎖在每次獲取和釋放鎖時(shí),都會(huì)帶來(lái)用戶態(tài)和內(nèi)核態(tài)的切換,這樣就增加了系統(tǒng)的性能開(kāi)銷。

          總結(jié)

          synchronized 在 JDK 1.6 時(shí)優(yōu)化了其性能,在一系列優(yōu)化的手段中,鎖膨脹是提升 synchronized 執(zhí)行效率的關(guān)鍵手段之一,鎖膨脹指的是 synchronized 會(huì)從無(wú)鎖狀態(tài)、到偏向鎖、到輕量級(jí)鎖,最后到重量級(jí)鎖的過(guò)程。重量級(jí)之前的所有狀態(tài)在絕大數(shù)情況下可以大幅的提升 synchronized 的性能。

          本系列推薦文章

          1.線程的故事:我的3位母親成就了優(yōu)秀的我!
          2.線程池的7種創(chuàng)建方式,強(qiáng)烈推薦你用它...
          3.輕量級(jí)鎖一定比重量級(jí)鎖快嗎?
          4.這樣終止線程,竟然會(huì)導(dǎo)致服務(wù)宕機(jī)?
          5.漫畫(huà):如何證明sleep不釋放鎖,而wait釋放鎖?
          6.池化技術(shù)到達(dá)有多牛?看了線程和線程池的對(duì)比嚇我一跳!
          7.求求你,別再用wait和notify了!
          8.Semaphore自白:限流器用我就對(duì)了!
          9.CountDownLatch:別浪,等人齊再團(tuán)!
          10.CyclicBarrier:人齊了,老司機(jī)就發(fā)車了!
          11.Java中用戶線程和守護(hù)線程區(qū)別這么大?
          12.ThreadLocal不好用?那是你沒(méi)用對(duì)!
          13.ThreadLocal內(nèi)存溢出代碼演示和原因分析!
          14.SimpleDateFormat線程不安全的5種解決方案!
          15.synchronized 加鎖 this 和 class 的區(qū)別!


          往期推薦

          synchronized 加鎖 this 和 class 的區(qū)別!


          使用了synchronized,竟然還有線程安全問(wèn)題!


          圖解Java中的18 把鎖!


          瀏覽 57
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          評(píng)論
          圖片
          表情
          推薦
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  天天干,夜夜操 | 美女的尿口视频网站 | 11久久 | 网站日逼 | 影音先锋中文字幕一区 |