柚子快報(bào)激活碼778899分享：JVM之CMS垃圾收集器詳解

http://yzkb.51969.com/

CMS垃圾收集器

CMS回收流程

官網(wǎng)： https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html#concurrent_mark_sweep_cms_collector

CMS(Concurrent Mark Sweep)收集器是一種以獲取 最短回收停頓時(shí)間為目標(biāo)的收集器。

采用的是"標(biāo)記-清除算法",整個(gè)過(guò)程分為4步

(1)初始標(biāo)記 CMS initial mark 標(biāo)記GC Roots直接關(guān)聯(lián)對(duì)象，不用Tracing，速度很快

(2)并發(fā)標(biāo)記 CMS concurrent mark 進(jìn)行GC Roots Tracing

(3)重新標(biāo)記 CMS remark 修改并發(fā)標(biāo)記因用戶程序變動(dòng)的內(nèi)容

(4)并發(fā)清除 CMS concurrent sweep 清除不可達(dá)對(duì)象回收空間，同時(shí)有新垃圾產(chǎn)生，留著下次清理稱(chēng)為浮動(dòng)垃圾

由于整個(gè)過(guò)程中，并發(fā)標(biāo)記和并發(fā)清除，收集器線程可以與用戶線程一起工作，所以總體上來(lái)說(shuō)，CMS收集器的內(nèi)存回收過(guò)程是與用戶線程一起并發(fā)地執(zhí)行的。

優(yōu)點(diǎn)：并發(fā)收集、低停頓

缺點(diǎn)：產(chǎn)生大量空間碎片、并發(fā)階段會(huì)降低吞吐量

第一個(gè)問(wèn)題：為什么我的CMS回收流程圖上初始標(biāo)記是單線程，為什么不使用多線程呢？

初始化標(biāo)記階段是串行的，這是JDK7的行為。JDK8以后默認(rèn)是并行的，可以通過(guò)參數(shù)

-XX:+CMSParallelInitialMarkEnabled控制

CMS的兩種模式與一種特殊策略：

Backgroud CMS ：

實(shí)際上我們的并發(fā)標(biāo)記還能被整理成兩個(gè)流程

(1)初始標(biāo)記 (2)并發(fā)標(biāo)記 (3)并發(fā)預(yù)處理 (4)可中止的預(yù)處理 (5)重新標(biāo)記 (6)并發(fā)清除

為什么我們的并發(fā)標(biāo)記細(xì)化之后還會(huì)額外有兩個(gè)流程出現(xiàn)呢？

討論這個(gè)問(wèn)題之前，我們先思考一個(gè)問(wèn)題，假設(shè)CMS要進(jìn)行老年代的垃圾回收，我們?nèi)绾闻袛啾荒贻p代的對(duì)象引用的老年代對(duì)象是可達(dá)對(duì)象。

也就是這張圖，當(dāng)老年代被回收的時(shí)候，我們?nèi)绾闻袛郃對(duì)象是存活對(duì)象。

答：必須掃描新生代來(lái)確定，所以CMS雖然是老年代的垃圾回收器，卻需要掃描新生代的原因。

問(wèn)題2：既然這個(gè)時(shí)候我需要掃描新生代，那么全量掃描會(huì)不會(huì)很慢

答：肯定會(huì)的 ，但是接踵而來(lái)的問(wèn)題：既然會(huì)很慢，我們的停頓時(shí)間很長(zhǎng)，可是CMS的目標(biāo)是什么

CMS(Concurrent Mark Sweep)收集器是一種以獲取 最短回收停頓時(shí)間為目標(biāo)的收集器。這不是與他的設(shè)計(jì)理念不一致嗎？

思考：怎么讓我們的回收變快

答：肯定是垃圾越少越快。所以我們的CMS想到了一種方式，就是我先進(jìn)行新生代的垃圾回收，也就是一次young GC，回收完畢之后。是不是我們新生代的對(duì)象就變少了，那么我再進(jìn)行垃圾回收，是不是就變快了。

所以，CMS有兩個(gè)參數(shù)：

CMSScheduleRemarkEdenSizeThreshold 默認(rèn)值：2M

CMSScheduleRemarkEdenPenetration 默認(rèn)值：50%

這兩個(gè)參數(shù)組合起來(lái)就是預(yù)清理之后，Eden空間使用超過(guò)2M的時(shí)候啟動(dòng)可中斷的并發(fā)預(yù)清理（CMS-concurrent-abortable-preclean），到Eden空間使用率到達(dá)50%的時(shí)候中斷（但不是結(jié)束），進(jìn)入Remark（重新標(biāo)記階段）。

這里面有個(gè)概念，老師，為什么并發(fā)預(yù)處理前面會(huì)有可中斷幾個(gè)字呢？什么意思。

可中斷意味著，假設(shè)你一直在預(yù)處理，預(yù)處理是干什么，無(wú)非就是去幫你把正式應(yīng)該處理的前置工作給做了。所以他一定干了很多事情，但是這些事情遲早有個(gè)頭，所以就設(shè)置了一個(gè)時(shí)間對(duì)他進(jìn)行打斷。所以，并發(fā)預(yù)處理的邏輯是當(dāng)你發(fā)生了minor GC ，我就預(yù)處理結(jié)束了。

這里有個(gè)問(wèn)題，我怎么知道你什么時(shí)候發(fā)生minor GC

答：答案是我不知道，垃圾回收是JVM自動(dòng)調(diào)度的，所以我們無(wú)法控制垃圾回收。

那我不可能無(wú)限制的執(zhí)行下去，總要有個(gè)結(jié)束時(shí)間吧

CMS提供了一個(gè)參數(shù)CMSMaxAbortablePrecleanTime ，默認(rèn)為5S

只要到了5S，不管發(fā)沒(méi)發(fā)生Minor GC，有沒(méi)有到CMSScheduleRemardEdenPenetration都會(huì)中止此階段，進(jìn)入remark。

如果在5S內(nèi)還是沒(méi)有執(zhí)行Minor GC怎么辦？

CMS提供CMSScavengeBeforeRemark參數(shù)，使remark前強(qiáng)制進(jìn)行一次Minor GC。

到這里，新生代策略已經(jīng)聊完了

接下來(lái)老年代的話，有幾個(gè)重要的點(diǎn)先給大家聊一下。

記憶集

當(dāng)我們進(jìn)行young gc時(shí)，我們的gc roots除了常見(jiàn)的棧引用、靜態(tài)變量、常量、鎖對(duì)象、class對(duì)象這些常見(jiàn)的之外，如果 老年代有對(duì)象引用了我們的新生代對(duì)象 ，那么老年代的對(duì)象也應(yīng)該加入gc roots的范圍中，但是如果每次進(jìn)行young gc我們都需要掃描一次老年代的話，那我們進(jìn)行垃圾回收的代價(jià)實(shí)在是太大了，因此我們引入了一種叫做記憶集的抽象數(shù)據(jù)結(jié)構(gòu)來(lái)記錄這種引用關(guān)系。

記憶集是一種用于記錄從非收集區(qū)域指向收集區(qū)域的指針集合的數(shù)據(jù)結(jié)構(gòu)。

如果我們不考慮效率和成本問(wèn)題，我們可以用一個(gè)數(shù)組存儲(chǔ)所有有指針指向新生代的老年代對(duì)象。但是如果這樣的話我們維護(hù)成本就很好，打個(gè)比方，假如所有的老年代對(duì)象都有指針指向了新生代，那么我們需要維護(hù)整個(gè)老年代大小的記憶集，毫無(wú)疑問(wèn)這種方法是不可取的。因此我們引入了卡表的數(shù)據(jù)結(jié)構(gòu)

卡表

記憶集是我們針對(duì)于跨代引用問(wèn)題提出的思想，而卡表則是針對(duì)于該種思想的具體實(shí)現(xiàn)。（可以理解為記憶集是結(jié)構(gòu)，卡表是實(shí)現(xiàn)類(lèi)）

[1字節(jié)，00001000，1字節(jié)，1字節(jié)]

在hotspot虛擬機(jī)中，卡表是一個(gè)字節(jié)數(shù)組，數(shù)組的每一項(xiàng)對(duì)應(yīng)著內(nèi)存中的某一塊連續(xù)地址的區(qū)域，如果該區(qū)域中有引用指向了待回收區(qū)域的對(duì)象，卡表數(shù)組對(duì)應(yīng)的元素將被置為1，沒(méi)有則置為0；

(1) 卡表是使用一個(gè)字節(jié)數(shù)組實(shí)現(xiàn):CARD_TABLE[],每個(gè)元素對(duì)應(yīng)著其標(biāo)識(shí)的內(nèi)存區(qū)域一塊特定大小的內(nèi)存塊,稱(chēng)為"卡頁(yè)"。hotSpot使用的卡頁(yè)是2^9大小,即512字節(jié)

(2) 一個(gè)卡頁(yè)中可包含多個(gè)對(duì)象,只要有一個(gè)對(duì)象的字段存在跨代指針,其對(duì)應(yīng)的卡表的元素標(biāo)識(shí)就變成1,表示該元素變臟,否則為0。GC時(shí),只要篩選本收集區(qū)的卡表中變臟的元素加入GC Roots里。

卡表的使用圖例

并發(fā)標(biāo)記的時(shí)候，A對(duì)象發(fā)生了所在的引用發(fā)生了變化，所以A對(duì)象所在的塊被標(biāo)記為臟卡

繼續(xù)往下到了重新標(biāo)記階段，修改對(duì)象的引用，同時(shí)清除臟卡標(biāo)記。

卡表其他作用：

老年代識(shí)別新生代的時(shí)候

對(duì)應(yīng)的card table被標(biāo)識(shí)為相應(yīng)的值（card table中是一個(gè)byte，有八位，約定好每一位的含義就可區(qū)分哪個(gè)是引用新生代，哪個(gè)是并發(fā)標(biāo)記階段修改過(guò)的）

Foregroud CMS：

其實(shí)這個(gè)也是CMS一種收集模式，但是他是并發(fā)失敗才會(huì)走的模式。這里聊到一個(gè)概念，什么是并發(fā)失敗呢？

并發(fā)失敗官方的描述是：

如果 并發(fā)搜集器不能在年老代填滿之前完成不可達(dá)（unreachable）對(duì)象的回收 ，或者 年老代中有效的空閑內(nèi)存空間不能滿足某一個(gè)內(nèi)存的分配請(qǐng)求 ，此時(shí)應(yīng)用會(huì)被暫停，并在此暫停期間開(kāi)始垃圾回收，直到回收完成才會(huì)恢復(fù)應(yīng)用程序。這種無(wú)法并發(fā)完成搜集的情況就成為 并發(fā)模式失?。╟oncurrent mode failure） ，而且這種情況的發(fā)生也意味著我們需要調(diào)節(jié)并發(fā)搜集器的參數(shù)了。

簡(jiǎn)單來(lái)說(shuō)，也就是我去進(jìn)行并發(fā)標(biāo)記的時(shí)候，內(nèi)存不夠了，這個(gè)時(shí)候我會(huì)進(jìn)入STW，并且開(kāi)始全局Full GC.

那么什么時(shí)候會(huì)進(jìn)行并發(fā)失敗呢 換句話說(shuō)，我們的難道非要滿了之后才進(jìn)行收集

-XX:CMSInitiatingOccupancyFraction

-XX:+UseCMSInitiatingOccupancyOnly

注意：-XX:+UseCMSInitiatingOccupancyOnly 只是用設(shè)定的回收閾值(上面指定的70%),如果不指定,JVM僅在第一次使用設(shè)定值,后續(xù)則自動(dòng)調(diào)整.這兩個(gè)參數(shù)表示只有在Old區(qū)占了CMSInitiatingOccupancyFraction設(shè)置的百分比的內(nèi)存時(shí)才滿足觸發(fā)CMS的條件。注意這只是滿足觸發(fā)CMS GC的條件。至于什么時(shí)候真正觸發(fā)CMS GC，由一個(gè)后臺(tái)掃描線程決定。CMSThread默認(rèn)2秒鐘掃描一次，判斷是否需要觸發(fā)CMS，這個(gè)參數(shù)可以更改這個(gè)掃描時(shí)間間隔。

看源碼公式：

((100 - MinHeapFreeRatio) + (double)( CMSTriggerRatio * MinHeapFreeRatio) / 100.0) / 100.0

也就是按照默認(rèn)值

當(dāng)老年代達(dá)到 ((100 - 40) + (double) 80 * 40 / 100 ) / 100 = 92 %時(shí)，會(huì)觸發(fā)CMS回收。

如何避免他的出現(xiàn)：

為了盡量避免并發(fā)模式失敗發(fā)生，我們可以調(diào)節(jié)-XX:CMSInitiatingOccupancyFraction=參數(shù)，去控制當(dāng)年老代的內(nèi)存占用達(dá)到多少的時(shí)候（N%），便開(kāi)啟并發(fā)搜集器開(kāi)始回收年老代。

CMS的標(biāo)記壓縮算法-----MSC（Mark Sweep Compact）

他的回收方式其實(shí)就是我們的滑動(dòng)整理，并且進(jìn)行整理的時(shí)候一般都是兩個(gè)參數(shù)

-XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction=0

這兩個(gè)參數(shù)表示多少次FullGC后采用MSC算法壓縮堆內(nèi)存，0表示每次FullGC后都會(huì)壓縮，同時(shí)0也是默認(rèn)值

碎片問(wèn)題也是CMS采用的標(biāo)記清理算法最讓人詬病的地方：Backgroud CMS采用的標(biāo)記清理算法會(huì)導(dǎo)致內(nèi)存碎片問(wèn)題，從而埋下發(fā)生FullGC導(dǎo)致長(zhǎng)時(shí)間STW的隱患。

所以如果觸發(fā)了FullGC，無(wú)論是否會(huì)采用MSC算法壓縮堆，那都是ParNew+CMS組合非常糟糕的情況。因?yàn)檫@個(gè)時(shí)候并發(fā)模式已經(jīng)搞不定了，而且整個(gè)過(guò)程單線程，完全STW，可能會(huì)壓縮堆（是否壓縮堆通過(guò)上面兩個(gè)參數(shù)控制），真的不能再糟糕了！想象如果這時(shí)候業(yè)務(wù)量比較大，由于FullGC導(dǎo)致服務(wù)完全暫停幾秒鐘，甚至上10秒，對(duì)用戶體驗(yàn)影響得多大。

三色標(biāo)記

在并發(fā)標(biāo)記的過(guò)程中，因?yàn)闃?biāo)記期間應(yīng)用線程還在繼續(xù)跑，對(duì)象間的引用可能發(fā)生變化，多標(biāo)和漏標(biāo)的情況就有可能發(fā)生。這里引入“三色標(biāo)記”來(lái)給大家解釋下，把Gcroots可達(dá)性分析遍歷對(duì)象過(guò)程中遇到的對(duì)象， 按照“是否訪問(wèn)過(guò)”這個(gè)條件標(biāo)記成以下三種顏色：

黑色：

表示對(duì)象已經(jīng)被垃圾收集器訪問(wèn)過(guò)， 且這個(gè)對(duì)象的所有引用都已經(jīng)掃描過(guò)。 黑色的對(duì)象代表已經(jīng)掃描過(guò)， 它是安全存活的， 如果有其他對(duì)象引用指向了黑色對(duì)象， 無(wú)須重新掃描一遍。 黑色對(duì)象不可能直接（不經(jīng)過(guò)灰色對(duì)象） 指向某個(gè)白色對(duì)象。

灰色：

表示對(duì)象已經(jīng)被垃圾收集器訪問(wèn)過(guò)， 但這個(gè)對(duì)象上至少存在一個(gè)引用還沒(méi)有被掃描過(guò)。

白色:

表示對(duì)象尚未被垃圾收集器訪問(wèn)過(guò)。 顯然在可達(dá)性分析剛剛開(kāi)始的階段， 所有的對(duì)象都是白色的， 若在分析結(jié)束的階段， 仍然是白色的對(duì)象， 即代表不可達(dá)。

標(biāo)記過(guò)程：

1.初始時(shí)，所有對(duì)象都在 【白色集合】中；

2.將GC Roots 直接引用到的對(duì)象 挪到 【灰色集合】中；

3.從灰色集合中獲取對(duì)象：

將本對(duì)象 引用到的 其他對(duì)象 全部挪到 【灰色集合】中；將本對(duì)象 挪到 【黑色集合】里面。

重復(fù)步驟3.4，直至【灰色集合】為空時(shí)結(jié)束。

結(jié)束后，仍在【白色集合】的對(duì)象即為GC Roots 不可達(dá)，可以進(jìn)行回收

多標(biāo)-浮動(dòng)垃圾

在并發(fā)標(biāo)記過(guò)程中，如果由于方法運(yùn)行結(jié)束導(dǎo)致部分局部變量(gcroot)被銷(xiāo)毀，這個(gè)gcroot引用的對(duì)象之前又被掃描過(guò) (被標(biāo)記為非垃圾對(duì)象)，那么本輪GC不會(huì)回收這部分內(nèi)存。這部分本應(yīng)該回收但是沒(méi)有回收到的內(nèi)存，被稱(chēng)之為“浮動(dòng) 垃圾”。浮動(dòng)垃圾并不會(huì)影響垃圾回收的正確性，只是需要等到下一輪垃圾回收中才被清除。

另外，針對(duì)并發(fā)標(biāo)記(還有并發(fā)清理)開(kāi)始后產(chǎn)生的新對(duì)象，通常的做法是直接全部當(dāng)成黑色，本輪不會(huì)進(jìn)行清除。這部分 對(duì)象期間可能也會(huì)變?yōu)槔?，這也算是浮動(dòng)垃圾的一部分。

漏標(biāo)-讀寫(xiě)屏障

漏標(biāo)只有同時(shí)滿足以下兩個(gè)條件時(shí)才會(huì)發(fā)生：

條件一：灰色對(duì)象 斷開(kāi)了 白色對(duì)象的引用；即灰色對(duì)象 原來(lái)成員變量的引用 發(fā)生了變化。

條件二：黑色對(duì)象 重新引用了 該白色對(duì)象；即黑色對(duì)象 成員變量增加了 新的引用。

漏標(biāo)會(huì)導(dǎo)致被引用的對(duì)象被當(dāng)成垃圾誤刪除，這是嚴(yán)重bug，必須解決，有兩種解決方案： 增量更新（Incremental Update） 和原始快照（Snapshot At The Beginning，SATB） 。

增量更新就是當(dāng)黑色對(duì)象插入新的指向白色對(duì)象的引用關(guān)系時(shí)， 就將這個(gè)新插入的引用記錄下來(lái)， 等并發(fā)掃描結(jié)束之后， 再將這些記錄過(guò)的引用關(guān)系中的黑色對(duì)象為根， 重新掃描一次。 這可以簡(jiǎn)化理解為， 黑色對(duì)象一旦新插入了指向白色對(duì)象的引用之后， 它就變回灰色對(duì)象了。

原始快照就是當(dāng)灰色對(duì)象要?jiǎng)h除指向白色對(duì)象的引用關(guān)系時(shí)， 就將這個(gè)要?jiǎng)h除的引用記錄下來(lái)， 在并發(fā)掃描結(jié)束之后， 再將這些記錄過(guò)的引用關(guān)系中的灰色對(duì)象為根， 重新掃描一次，這樣就能掃描到白色的對(duì)象，將白色對(duì)象直接標(biāo)記為黑色(目的就是讓這種對(duì)象在本輪gc清理中能存活下來(lái)，待下一輪gc的時(shí)候重新掃描，這個(gè)對(duì)象也有可能是浮動(dòng)垃圾)

以上無(wú)論是對(duì)引用關(guān)系記錄的插入還是刪除， 虛擬機(jī)的記錄操作都是通過(guò)寫(xiě)屏障實(shí)現(xiàn)的。

寫(xiě)屏障實(shí)現(xiàn)原始快照（SATB）： 當(dāng)對(duì)象B的成員變量的引用發(fā)生變化時(shí)，比如引用消失（a.b.d = null），我們可以利用寫(xiě)屏障，將B原來(lái)成員變量的引用對(duì)象D記錄下來(lái)：

寫(xiě)屏障實(shí)現(xiàn)增量更新： 當(dāng)對(duì)象A的成員變量的引用發(fā)生變化時(shí)，比如新增引用（a.d = d），我們可以利用寫(xiě)屏障，將A新的成員變量引用對(duì)象D 記錄下來(lái)：

CMS標(biāo)記清除的全局整理：

由于CMS使用的是標(biāo)記清除算法，而標(biāo)記清除算法會(huì)有大量的內(nèi)存碎片的產(chǎn)生，所以JVM提供了

-XX:+UseCMSCompactAtFullCollection參數(shù)用于在全局GC（full GC）后進(jìn)行一次碎片整理的工作，

由于每次全局GC后都進(jìn)行碎片整理會(huì)較大的影響停頓時(shí)間，JVM又提供了參數(shù)

-XX:CMSFullGCsBeforeCompaction去 控制在幾次全局GC后會(huì)進(jìn)行碎片整理 。

CMS常用參數(shù)含義：

-XX:+UseConcMarkSweepGC

打開(kāi)CMS GC收集器。JVM在1.8之前默認(rèn)使用的是Parallel GC，9以后使用G1 GC。

-XX:+UseParNewGC

當(dāng)使用CMS收集器時(shí)，默認(rèn)年輕代使用多線程并行執(zhí)行垃圾回收（UseConcMarkSweepGC開(kāi)啟后則默認(rèn)開(kāi)啟）。

-XX:+CMSParallelRemarkEnabled

采用并行標(biāo)記方式降低停頓（默認(rèn)開(kāi)啟）。

-XX:+CMSConcurrentMTEnabled

被啟用時(shí)，并發(fā)的CMS階段將以多線程執(zhí)行（因此，多個(gè)GC線程會(huì)與所有的應(yīng)用程序線程并行工作）。（默認(rèn)開(kāi)啟）

-XX:ConcGCThreads

定義并發(fā)CMS過(guò)程運(yùn)行時(shí)的線程數(shù)。

-XX:ParallelGCThreads

定義CMS過(guò)程并行收集的線程數(shù)。

-XX:CMSInitiatingOccupancyFraction

該值代表老年代堆空間的使用率，默認(rèn)值為68。當(dāng)老年代使用率達(dá)到此值之后，并行收集器便開(kāi)始進(jìn)行垃圾收集，該參數(shù)需要配合UseCMSInitiatingOccupancyOnly一起使用，單獨(dú)設(shè)置無(wú)效。

-XX:+UseCMSInitiatingOccupancyOnly

該參數(shù)啟用后，參數(shù)CMSInitiatingOccupancyFraction才會(huì)生效。默認(rèn)關(guān)閉。

-XX:+CMSClassUnloadingEnabled

相對(duì)于并行收集器，CMS收集器默認(rèn)不會(huì)對(duì)永久代進(jìn)行垃圾回收。如果希望對(duì)永久代進(jìn)行垃圾回收，可用設(shè)置-XX:+CMSClassUnloadingEnabled。默認(rèn)關(guān)閉。

-XX:+CMSIncrementalMode

開(kāi)啟CMS收集器的增量模式。增量模式使得回收過(guò)程更長(zhǎng)，但是暫停時(shí)間往往更短。默認(rèn)關(guān)閉。

-XX:CMSFullGCsBeforeCompaction

設(shè)置在執(zhí)行多少次Full GC后對(duì)內(nèi)存空間進(jìn)行壓縮整理，默認(rèn)值0。

-XX:+CMSScavengeBeforeRemark

在cms gc remark之前做一次ygc，減少gc roots掃描的對(duì)象數(shù)，從而提高remark的效率，默認(rèn)關(guān)閉。

-XX:+ExplicitGCInvokesConcurrent

該參數(shù)啟用后JVM無(wú)論什么時(shí)候調(diào)用系統(tǒng)GC，都執(zhí)行CMS GC，而不是Full GC。

-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses

該參數(shù)保證當(dāng)有系統(tǒng)GC調(diào)用時(shí)，永久代也被包括進(jìn)CMS垃圾回收的范圍內(nèi)。

-XX:+DisableExplicitGC

該參數(shù)將使JVM完全忽略系統(tǒng)的GC調(diào)用（不管使用的收集器是什么類(lèi)型）。

-XX:+UseCompressedOops

這個(gè)參數(shù)用于對(duì)類(lèi)對(duì)象數(shù)據(jù)進(jìn)行壓縮處理，提高內(nèi)存利用率。（默認(rèn)開(kāi)啟）

-XX:MaxGCPauseMillis=200

這個(gè)參數(shù)用于設(shè)置GC暫停等待時(shí)間，單位為毫秒，不要設(shè)置過(guò)低。

CMS的線程數(shù)計(jì)算公式

區(qū)分young區(qū)的parnew gc線程數(shù)和old區(qū)的cms線程數(shù)，分別為以下兩參數(shù)：

-XX:ParallelGCThreads=m // STW暫停時(shí)使用的GC線程數(shù)，一般用滿CPU-XX:ConcGCThreads=n // GC線程和業(yè)務(wù)線程并發(fā)執(zhí)行時(shí)使用的GC線程數(shù)，一般較小

ParallelGCThreads

其中ParallelGCThreads 參數(shù)的默認(rèn)值是：

CPU核心數(shù) <= 8，則為 ParallelGCThreads=CPU核心數(shù)，比如4C8G取4，8C16G取8CPU核心數(shù) > 8，則為 ParallelGCThreads = CPU核心數(shù) * 5/8 + 3 向下取整16核的情況下，ParallelGCThreads = 1332核的情況下，ParallelGCThreads = 2364核的情況下，ParallelGCThreads = 4372核的情況下，ParallelGCThreads = 48

ConcGCThreads

ConcGCThreads的默認(rèn)值則為：

ConcGCThreads = (ParallelGCThreads + 3)/4 向下取整。

ParallelGCThreads = 1~4時(shí)，ConcGCThreads = 1ParallelGCThreads = 5~8時(shí)，ConcGCThreads = 2ParallelGCThreads = 13~16時(shí)，ConcGCThreads = 4

CMS推薦配置參數(shù)：

第一種情況：8C16G左右服務(wù)器，再大的服務(wù)器可以上G1了 沒(méi)必要

-Xmx12g -Xms12g

-XX:ParallelGCThreads=8

-XX:ConcGCThreads=2

-XX:+UseConcMarkSweepGC

-XX:+CMSClassUnloadingEnabled

-XX:+CMSIncrementalMode

-XX:+CMSScavengeBeforeRemark

-XX:+UseCMSInitiatingOccupancyOnly

-XX:CMSInitiatingOccupancyFraction=70

-XX:CMSFullGCsBeforeCompaction=5

-XX:MaxGCPauseMillis=100 // 按業(yè)務(wù)情況來(lái)定

-XX:+ExplicitGCInvokesConcurrent

-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses

-XX:+PrintGCTimeStamps

-XX:+PrintGCDetails

-XX:+PrintGCDateStamps

第二種情況：4C8G

-Xmx6g -Xms6g

-XX:ParallelGCThreads=4

-XX:ConcGCThreads=1

-XX:+UseConcMarkSweepGC

-XX:+CMSClassUnloadingEnabled

-XX:+CMSIncrementalMode

-XX:+CMSScavengeBeforeRemark

-XX:+UseCMSInitiatingOccupancyOnly

-XX:CMSInitiatingOccupancyFraction=70

-XX:CMSFullGCsBeforeCompaction=5

-XX:MaxGCPauseMillis=100 // 按業(yè)務(wù)情況來(lái)定

-XX:+ExplicitGCInvokesConcurrent

-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses

-XX:+PrintGCTimeStamps

-XX:+PrintGCDetails

-XX:+PrintGCDateStamps

第三種情況：2C4G，這種情況下，也不推薦使用，因?yàn)?C的情況下，線程上下文的開(kāi)銷(xiāo)比較大，性能可能還不如你不動(dòng)的情況，沒(méi)必要。非要用，給你個(gè)配置，你自己玩。

-Xmx3g -Xms3g

-XX:ParallelGCThreads=2

-XX:ConcGCThreads=1

-XX:+UseConcMarkSweepGC

-XX:+CMSClassUnloadingEnabled

-XX:+CMSIncrementalMode

-XX:+CMSScavengeBeforeRemark

-XX:+UseCMSInitiatingOccupancyOnly

-XX:CMSInitiatingOccupancyFraction=70

-XX:CMSFullGCsBeforeCompaction=5

-XX:MaxGCPauseMillis=100 // 按業(yè)務(wù)情況來(lái)定

-XX:+ExplicitGCInvokesConcurrent

-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses

-XX:+PrintGCTimeStamps

-XX:+PrintGCDetails

-XX:+PrintGCDateStamps

柚子快報(bào)激活碼778899分享：JVM之CMS垃圾收集器詳解

http://yzkb.51969.com/

精彩內(nèi)容