每周分享一個JVM參數(shù)

今天分享的參數(shù)是 -XX:ParGCCardsPerStrideChunk

diagnostic(intx, ParGCCardsPerStrideChunk, 256,                           \
 "The number of cards in each chunk of the parallel chunks used during card table scanning")

一個神奇的參數(shù)婶熬,看描述似乎還是比較迷糊议谷,還是展開來說下。

發(fā)生young gc時丛忆,有一個特殊的GC Roots逗栽,那就是old gen中的對象盖袭,當old gen的對象A引用了young gen的對象B,那么對象B是不能被回收的彼宠。

所以要在old gen中找出所有和對象A類似的對象(引用了young gen對象)鳄虱,怎么找呢?最暴力的辦法就是遍歷所有的old gen對象凭峡,顯然這種方式效率很低下拙已,在HotSpot實現(xiàn)中,提供了一種叫CardTable的數(shù)據(jù)結(jié)構(gòu)摧冀,用來表示一塊內(nèi)存區(qū)域倍踪,一般是512字節(jié),如果這塊內(nèi)存中有對象引用了young gen對象索昂,那么就標識這個CardTable為Dirty的建车,這樣在內(nèi)存掃描時,只需要掃描標識為Dirty的內(nèi)存區(qū)域中的對象即可椒惨,避免了全old gen的掃描缤至,大大提升了掃描效率。

在ParNew算法中康谆,掃描old gen的CardTable由多個線程完成领斥,其中ParGCCardsPerStrideChunk參數(shù)就是每個線程處理的CardTable數(shù)量,默認是256個沃暗,意思每個線程每次處理大小為 256*512byte = 128K的StrideChunk月洛,如果old gen大小4G,那么一共要處理 4G / 128K = 32K個StrideChunk描睦,這么多的StrideChunk要分配給GC線程膊存,假設(shè)有4個線程在并發(fā)執(zhí)行导而,必然存在任務(wù)的調(diào)度和分配問題忱叭,影響到掃描效率隔崎。

如果把這個參數(shù)調(diào)大,那么每個線程每次處理的StrideChunk也相應(yīng)變大韵丑,總的StrideChunk個數(shù)相應(yīng)的減少爵卒,GC線程在不同的StrideChunk切換次數(shù)也會減少,這樣是不是可以提升一點性能呢撵彻?

那么應(yīng)該調(diào)到多大呢钓株?之前看過一篇LinkedIn的Engineering Blog,他們在不同的配置下經(jīng)過測試之后得出了32768是最佳值的結(jié)論陌僵,后來很多的人覺得這個值很神奇轴合,不假思索的也設(shè)置了這個值,但這個值真的適合你的應(yīng)用么碗短?這個非常值得懷疑受葛。

之后Twitter的一批人也高了一個OpenJDK的測試,他們發(fā)現(xiàn)8192是一個合適的值偎谁,公說公有理总滩,婆說婆有理,我們不用太較真巡雨,抱著學(xué)習(xí)的心態(tài)就行闰渔。

最后,我們看看這個參數(shù)的提交者怎么說铐望,一個俄國人Alexey Ragozin冈涧,這是他的一篇關(guān)于該參數(shù)的文章,傳送門正蛙,他在發(fā)現(xiàn)CardTable掃描時的效率問題后炕舵,在7u40時patch了這個問題,在他的實驗中跟畅,對28G和14G分別咽筋,且該參數(shù)設(shè)置成4K,結(jié)果如下:

不管怎么說徊件,在他的實驗中奸攻,GC性能確實提升不少,但也不能說明4K就是一個完美值虱痕,該值也只是非常符合他當前的實驗而已睹耐。

仔細想想,如果old gen中需要掃描的CardTable其實不多部翘,如果盲目的增大該參數(shù)硝训,也會得不償失,這時256未嘗不是一個合適的值,需要找到一個平衡點窖梁。

因為該參數(shù)是diagnostic類型的赘风,所以要使修改的值生效,需要添加下面參數(shù):

-XX:+UnlockDiagnosticVMOptions
-XX:ParGCCardsPerStrideChunk=4096

花了這么長時間來解釋這個參數(shù)纵刘,只是像說明一點邀窃,在JVM調(diào)優(yōu)過程中,沒有一個參數(shù)的值完美的假哎,只有經(jīng)過不斷的調(diào)優(yōu)過程瞬捕,慢慢的摸索到適合自己應(yīng)用的最佳參數(shù)范圍,除非應(yīng)用對YGC的耗時特別敏感舵抹,不到萬不得已肪虎,不用優(yōu)化該參數(shù),256也適合大部分情況惧蛹。但是隨著現(xiàn)在機器內(nèi)存的擴大笋轨,適當?shù)脑龃笤搮?shù)值(4K),也是沒有問題的赊淑。


我是占小狼爵政,如果覺得有收獲,歡迎關(guān)注陶缺。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末钾挟,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子饱岸,更是在濱河造成了極大的恐慌掺出,老刑警劉巖,帶你破解...
    沈念sama閱讀 218,941評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件苫费,死亡現(xiàn)場離奇詭異汤锨,居然都是意外死亡,警方通過查閱死者的電腦和手機百框,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,397評論 3 395
  • 文/潘曉璐 我一進店門闲礼,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人铐维,你說我怎么就攤上這事柬泽。” “怎么了嫁蛇?”我有些...
    開封第一講書人閱讀 165,345評論 0 356
  • 文/不壞的土叔 我叫張陵锨并,是天一觀的道長。 經(jīng)常有香客問我睬棚,道長第煮,這世上最難降的妖魔是什么解幼? 我笑而不...
    開封第一講書人閱讀 58,851評論 1 295
  • 正文 為了忘掉前任,我火速辦了婚禮包警,結(jié)果婚禮上撵摆,老公的妹妹穿的比我還像新娘。我一直安慰自己揽趾,他們只是感情好台汇,可當我...
    茶點故事閱讀 67,868評論 6 392
  • 文/花漫 我一把揭開白布苛骨。 她就那樣靜靜地躺著篱瞎,像睡著了一般。 火紅的嫁衣襯著肌膚如雪痒芝。 梳的紋絲不亂的頭發(fā)上俐筋,一...
    開封第一講書人閱讀 51,688評論 1 305
  • 那天,我揣著相機與錄音严衬,去河邊找鬼澄者。 笑死,一個胖子當著我的面吹牛请琳,可吹牛的內(nèi)容都是我干的粱挡。 我是一名探鬼主播,決...
    沈念sama閱讀 40,414評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼俄精,長吁一口氣:“原來是場噩夢啊……” “哼询筏!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起竖慧,我...
    開封第一講書人閱讀 39,319評論 0 276
  • 序言:老撾萬榮一對情侶失蹤嫌套,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后圾旨,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體踱讨,經(jīng)...
    沈念sama閱讀 45,775評論 1 315
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,945評論 3 336
  • 正文 我和宋清朗相戀三年砍的,在試婚紗的時候發(fā)現(xiàn)自己被綠了痹筛。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,096評論 1 350
  • 序言:一個原本活蹦亂跳的男人離奇死亡廓鞠,死狀恐怖味混,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情诫惭,我是刑警寧澤翁锡,帶...
    沈念sama閱讀 35,789評論 5 346
  • 正文 年R本政府宣布,位于F島的核電站夕土,受9級特大地震影響馆衔,放射性物質(zhì)發(fā)生泄漏瘟判。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,437評論 3 331
  • 文/蒙蒙 一角溃、第九天 我趴在偏房一處隱蔽的房頂上張望拷获。 院中可真熱鬧,春花似錦减细、人聲如沸匆瓜。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,993評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽驮吱。三九已至,卻和暖如春萧吠,著一層夾襖步出監(jiān)牢的瞬間左冬,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,107評論 1 271
  • 我被黑心中介騙來泰國打工纸型, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留拇砰,地道東北人。 一個月前我還...
    沈念sama閱讀 48,308評論 3 372
  • 正文 我出身青樓狰腌,卻偏偏與公主長得像除破,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子琼腔,可洞房花燭夜當晚...
    茶點故事閱讀 45,037評論 2 355

推薦閱讀更多精彩內(nèi)容