色哟哟视频在线观看-色哟哟视频在线-色哟哟欧美15最新在线-色哟哟免费在线观看-国产l精品国产亚洲区在线观看-国产l精品国产亚洲区久久

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

由JVM的鎖機制導致的CPU占用率高問題

openEuler ? 來源:畢昇JDK社區 ? 作者:畢昇JDK社區 ? 2021-08-25 14:46 ? 次閱讀

編者按:筆者在 AArch64 中遇到一個 G1 GC 掛起,CPU 利用率高達 300%的案例。經過分析發現問題是由 JVM 的鎖機制導致,該問題根因是并發編程中沒有正確理解內存序導致。本文著重介紹 JVM 中 Monitor 的基本原理,同時演示了在什么情況下會觸發該問題。希望通過本文的分析,讀者能夠了解到內存序對性能、正確性的影響,在并發編程時更加仔細。

現象

本案例是一個典型的弱內存模型案例,大致的現象就是 AArch64 平臺上,業務掛死,而進程占用 CPU 持續維持在 300%。配合 top 和 gdb,可以看到是 3 個 GC 線程在 offer_termination 處陷入了死循環:

3e01a36e-e3d3-11eb-a97a-12bb97331649.png

多個并行 GC 線程在 Minor GC 結束時調用 offer_termination,在 offer_termination 中自旋等待其他并行 GC 線程到達該位置,才說明 GC 任務完成,可以終止。(關于并行任務的中止協議問題,可以參考相關論文,這里不做著重介紹。

簡單地說,在并行任務執行時,多個任務之間可能存在任務不均衡,所以 JVM 內部設計了任務均衡機制,同時必須設計任務終止的機制來保證多個任務都能完成,這里的 offer_termination 就是嘗試終止任務)。

在該案例中,部分 GC 線程完成自己的任務,等待其他的 GC 線程。此時出現掛起,很有可能是因為發生了死鎖。所以問題很可能是由于那些尚未完成任務的 GC 線程上錯誤地使用鎖。所以使用 gdb 觀察了一下其他 GC 線程,發現其他 GC 線程全都阻塞在一把 JVM 的鎖上:

3e318f52-e3d3-11eb-a97a-12bb97331649.png

而這把 Monitor 中的情況如下:

cxq 上積累了大量 GC 線程

OnDeck 記錄的 GC 線程已經消失

_owner 記錄的鎖持有者為 NULL

分析

在進一步分析前,首先普及一下 JVM 鎖組件 Monitor 的基本原理,Monitor 類主要包含 4 個核心字段:

“Thread * volatile _owner” 字段指向這把鎖的持有線程

“SplitWord_LockWord” 字段被設計為 1 個機器字長,目的是為了確保操作時天然的原子性,它的最低位被設計為上鎖標記位,而高位區域用來存放 256 字節對齊的競爭隊列(cxq)地址

“ParkEvent * volatile_EntryList” 字段指向一個等待隊列,跟 cxq 差別不大,個人理解只是為了緩解 cxq 的競爭壓力而設計

“ParkEvent * volatile_OnDeck” 字段指向這把鎖的法定繼承人,同時最低位還充當了內部鎖的角色

接下來通過一組流程圖來介紹加解鎖的具體流程:

3e44108c-e3d3-11eb-a97a-12bb97331649.png

上圖是加鎖的一個整體流程,大致分為 3 步:

首先走快速上鎖流程,主要對應鎖本身無人持有的最理想情況

3e5ff8ce-e3d3-11eb-a97a-12bb97331649.png

接著是自旋上鎖流程,這是預期將在短時間內獲取鎖的情況

3e6c45c0-e3d3-11eb-a97a-12bb97331649.png

最后是慢速上鎖流程,申請者將會加入等待隊列(cxq),然后進入睡眠,直到被喚醒后發現自己變成了法定繼承者,于是進入自旋,直到完成上鎖。

3e99cd9c-e3d3-11eb-a97a-12bb97331649.png

而且,基于性能考慮,整個上鎖流程中的每一步幾乎都做了“插隊”的嘗試:

3ec671c6-e3d3-11eb-a97a-12bb97331649.png

如上圖代碼中所示,“插隊”的意思就是不經過排隊(cxq),直接嘗試置上鎖標志位。

上圖就是整個解鎖流程了,顯然真正的解鎖操作在第二步中就已經完成了(意味著接下來時刻有“插隊”現象發生),剩下的主要就是選出繼承者的過程,大致分為以下幾步:

解鎖線程首先需要將內部鎖(_OnDeck)標記上鎖

從競爭隊列(cxq)抽取所有等待者放入等待隊列(_EntryList)

_ EntryList 取出頭一個元素,寫入_OnDeck 的同時解除內部鎖標記,這代表選出了繼承者

喚醒繼承者

當然伴隨著整個解鎖流程每一步的,還有對“插隊”行為的處理。

至此,JVM 鎖組件 Monitor 的原理就介紹到這里,再回歸到問題本身,一個疑問就是_OnDeck 上記錄的繼承者為何消失?作為繼承者,既然已經消失在競爭隊列和等待隊列里,顯然意味著它大概率已經持有鎖、然后解鎖走人了,所以問題很可能跟繼承者選取過程有關。基于這種猜測,我們對相關代碼著重進行了梳理,就發現了下圖兩處紅框標記位置存在疑點,那就是在選繼承者過程第 3 步中:

3ee5a3b6-e3d3-11eb-a97a-12bb97331649.png

寫EntryList 和寫_OnDeck 之間沒有 barrier 來保證執行順序,這可能出現_OnDeck 先于EntryList 寫入的情況,一旦繼承人提前持有鎖,后果就可能非常糟糕…

這里貼了一張可能的問題場景:

線程 A 處于解鎖流程中,由于亂序,先寫入了繼承者同時解除內部鎖

線程 B 處于上鎖流程,發現自己就是法定繼承者后,立刻完成上鎖

線程 B 又迅速進入解鎖流程,并從_EntryList 中取出頭元素(也就是線程 B!)作為繼承者寫入_OnDeck,完成解鎖走人

線程 A 此時才更新_EntryList,然后喚醒繼承者(也就是線程 B!),完成解鎖走人

_OnDeck 上的繼承者線程 B,實際已經完成加解鎖離開,后續等待線程再也無法被喚醒。

正巧在社區的高版本上找到了一個相關的修復記錄(JDK- 8166197),這里貼出 2 個關鍵的代碼片段:

3f6542ec-e3d3-11eb-a97a-12bb97331649.png

上面這段代碼位于慢速上鎖流程,被喚醒后檢查繼承者是否是自己,修復后的代碼在讀_OnDeck 時加了 Load-Acquire 的 barrier。

上面這段代碼位于解鎖時選繼承者流程,從_ EntryList 取出頭一個元素,寫入_OnDeck 的同時解除內部鎖標記,修復后的代碼在寫_OnDeck 時加了 Store-Release 的 barrier。

顯然,圍繞_OnDeck 添加的這對 One-way barrier 可以確保:當繼承者線程被喚醒時,該線程可以“看”到_EntryList 已經被及時更新。

總結:

在 AArch64 這種弱內存模型的平臺上(關于內存序更多的知識在接下來的分享中會詳細介紹),一旦涉及多線程對公共內存的每一次訪問,必須反復確認是否需要通過 barrier 來嚴格保序,而且除非存在有效的依賴關系,否則 barrier 需要在讀寫端成對使用。

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • cpu
    cpu
    +關注

    關注

    68

    文章

    10854

    瀏覽量

    211588
  • JVM
    JVM
    +關注

    關注

    0

    文章

    158

    瀏覽量

    12220

原文標題:JVM 鎖 bug 導致 G1 GC 掛起問題分析和解決

文章出處:【微信號:openEulercommunity,微信公眾號:openEuler】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    CPU占用率過高的常見原因

    排查系統問題時,CPU 飆升是一個常見的問題。
    的頭像 發表于 10-23 09:33 ?482次閱讀

    服務器cpu占用率怎么解決

    服務器CPU占用率是一個常見的問題,它可能會導致服務器性能下降,甚至影響用戶體驗。 一、了解服務器CPU
    的頭像 發表于 10-10 15:14 ?899次閱讀

    從原理聊JVM(一):染色標記和垃圾回收算法

    導讀 JAVA簡單易用的特性,能夠讓研發人員在不了解JVM的底層運行機制的情況下依舊能夠編寫出功能完善的代碼。 但是對JVM的理解,是一個程序員普通和優秀的分水嶺。全面地了解JVM的工
    的頭像 發表于 08-20 15:25 ?228次閱讀
    從原理聊<b class='flag-5'>JVM</b>(一):染色標記和垃圾回收算法

    聊聊JVM如何優化

    首先應該明確的是JVM調優不是常規手段,JVM的存在本身就是為了減輕開發對于內存管理的負擔,當出現性能問題的時候第一時間考慮的是代碼邏輯與設計方案,以及是否達到依賴中間件的瓶頸,最后才是針對JVM
    的頭像 發表于 08-05 17:49 ?466次閱讀
    聊聊<b class='flag-5'>JVM</b>如何優化

    JAVA應用CPU跳點自動DUMP工具

    問題。如果CPU使用率過高,可能表示系統存在資源瓶頸,需要進行優化或升級。 CPU監控的難點 現有的監控平臺提供了多種方式來獲取容器和JVMCPU
    的頭像 發表于 08-05 17:48 ?523次閱讀

    自旋和互斥的使用場景是什么

    自旋和互斥是兩種常見的同步機制,它們在多線程編程中被廣泛使用。在本文中,我們將介紹自旋和互斥的使用場景,以及它們在不同場景下的優勢和
    的頭像 發表于 07-10 10:05 ?974次閱讀

    想通過perf工具來檢查2段不同代碼的內存占用率,但一直沒找到,怎么辦?

    想通過perf工具來檢查2段不同代碼的內存占用率,但一直沒找到,怎么辦?
    發表于 05-17 13:33

    恒訊科技全面解析:如何有效降低服務器CPU用率

    。 設置警報,以便在CPU使用率超過某個閾值時獲得通知。 2、識別CPU使用率的原因: 確定是特定進程、應用程序還是系統服務
    的頭像 發表于 05-10 17:24 ?711次閱讀

    鴻蒙OS開發實例:【ArkTS類庫多線程CPU密集型任務TaskPool】

    CPU密集型任務是指需要占用系統資源處理大量計算能力的任務,需要長時間運行,這段時間會阻塞線程其它事件的處理,不適宜放在主線程進行。例如圖像處理、視頻編碼、數據分析等。 基于多線程并發機制處理
    的頭像 發表于 04-01 22:25 ?832次閱讀
    鴻蒙OS開發實例:【ArkTS類庫多線程<b class='flag-5'>CPU</b>密集型任務TaskPool】

    借助英特爾? QAT從而顯著提升網絡和存儲應用的性能

    全新第四代和第五代英特爾? 至強? 可擴展處理器內置英特爾? 數據保護與壓縮加速技術(英特爾? QAT),可通過卸載計算密集型工作負載來降低 CPU 占用率,從而顯著提升網絡和存儲應用的性能。
    的頭像 發表于 03-18 16:25 ?980次閱讀
    借助英特爾? QAT從而顯著提升網絡和存儲應用的性能

    Linux系統CPU占用率100%的排查思路

    今天浩道跟大家分享linux硬核干貨,工作中當你服務器CPU達到100%時,干著急是沒有用的,該查問題還得自己去查。本文將給大家羅列排查異常故障思路,并且文末附上相關shell腳本,去實際一番,你會發現原來解決問題的方法如此之簡單!
    的頭像 發表于 01-23 10:26 ?5944次閱讀
    Linux系統<b class='flag-5'>CPU</b><b class='flag-5'>占用率</b>100%的排查思路

    使用adss軟件編譯程序卡住了的原因?

    使用 adss軟件編譯程序卡住在40 %,此時顯示編譯已經基本結束,CPU(因特爾i9-13)占用率從80% 降低到了 5 %,說明此時CPU基本已經停止編譯工作。但是編譯無法正常結束,卡住一小時后
    發表于 01-19 06:46

    如何使用TCM提高CPU性能?

    你好 我們正在使用 TRAVEO? T2G CYT4BF 的項目,CPU 占用率非常。 我們已經啟用了 Icache。 1。 我們想了解如何以最佳方式使用 ITCM 和 DTCM(CM7_0
    發表于 01-18 07:01

    如何在Linux系統中檢查CPU使用率

    首先在Linux系統中檢查CPU使用率。可以通過在命令行中輸入top或htop命令來查看當前系統中各個進程的CPU使用率。如果CPU使
    發表于 01-06 10:42 ?1309次閱讀
    如何在Linux系統中檢查<b class='flag-5'>CPU</b>使<b class='flag-5'>用率</b>

    NTP時間同步軟件chrony簡介和配置方法

    占用率、低內存消耗等優點。chrony兩個程序組成,chronyd(服務器端)和chronyc(客戶端)
    的頭像 發表于 01-02 10:45 ?6435次閱讀
    NTP時間同步軟件chrony簡介和配置方法
    主站蜘蛛池模板: china野外18:19| 国产网红主播精品福利大秀专区| 国产自产第一区c国产| 欧美日韩精品| 亚洲色综合中文字幕在线| 插骚妇好爽好骚| 久久视频这有精品63在线国产| 天上人间影院久久国产| 99九九99九九九视频精品| 狠狠色欧美亚洲狠狠色www| 日韩亚洲欧美中文在线| 2022久久精品国产色蜜蜜麻豆| 国产亚洲视频在线| 色婷婷亚洲精品天天综合影院 | 国产精品亚洲在钱视频| 浓毛BWBWBWBWBW日本| 一个人色导航| 国产日韩欧美高清免费视频 | 精品国产乱码久久久久久人妻 | 国产亚洲精品高清视频免费| 秋霞网站一级一片| 97超在线视频| 久久青青草原| 亚洲视频国产| 国产在线一区二区AV视频| 熟妇无码乱子成人精品| s8sp视频高清在线播放| 免费人妻无码AV不卡在线| 野草视频在线观看| 果冻传媒在线观看完整版免费| 十八禁久久成人一区二区| 超碰视频在线| 热中文热国产热综合| 99久久精品国产国产毛片| 考好老师让你做一次H| 伊人久久大香线蕉资源| 狠很橹快播| 亚洲欧美综合中文字幕| 国产在线观看免费观看不卡| 午夜欧洲亚洲AV永久无码精品| 国产成人免费网站在线观看|