JDK8中常用如下的垃圾收集器，它們分別運(yùn)用在年輕代和老年代：

• ParNew : 年輕代垃圾收集器，多線程，采用標(biāo)記—復(fù)制算法。

• CMS：老年代的收集器，全稱（Concurrent Mark and Sweep），是一種以獲取最短回收停頓時(shí)間為目標(biāo)的收集器。

可以通過如下JVM參數(shù)進(jìn)行配置：

-XX:+UseParNewGC

-XX:+UseConcMarkSweepGC

一、ParNew

意為“Parallel New Generation”，需要說明的是， ParNew雖然是個(gè)minor gc，但它會(huì)Stop-The-World。因此ParNew間隔時(shí)間越長(zhǎng)越好，并且每次執(zhí)行的時(shí)間越短越好。下面是一次ParNew打印的日志

[GC (Allocation Failure) [ParNew: 367523K->1293K(410432K), 0.0023988 secs] 522739K->156516K(1322496K), 0.0025301 secs] [Times: user=0.04 sys=0.00, real=0.01 secs]

其中的時(shí)間分別表示如下：

• 用戶態(tài)消耗的CPU時(shí)間
• 內(nèi)核態(tài)消耗的CPU事件
• 操作從開始到結(jié)束所經(jīng)過的墻鐘時(shí)間（Wall Clock Time）

這里需要說明一下CPU時(shí)間與墻鐘時(shí)間的區(qū)別：

墻鐘時(shí)間包括各種非運(yùn)算的等待耗時(shí)，例如等待磁盤I/O、等待線程阻塞，而CPU時(shí)間不包括這些耗時(shí)，但當(dāng)系統(tǒng)有多CPU或者多核的話，多線程操作會(huì)疊加這些CPU時(shí)間，所以讀者看到user或sys時(shí)間超過real時(shí)間是完全正常的。

因此在查看GC日志時(shí)，主要關(guān)注real對(duì)應(yīng)的時(shí)間。

二、CMS

意為“Concurrent Mark Sweep”，CMS主要分為如下幾個(gè)階段

• CMS-initial-mark???????????????????????????????? # 需要Stop the word
• CMS-concurrent-mark
• CMS-concurrent-preclean
• CMS-concurrent-abortable-preclean
• CMS-remark?????????????????????????????????????? # 需要Stop the word
• CMS-concurrent-sweep? ?
• CMS-initial-mark

這里需要特別關(guān)注CMS-initial-mark和CMS-remark這2個(gè)階段，因?yàn)檫@2 個(gè)階段需要Stop-The-World。對(duì)于CMS來說，也是間隔時(shí)間戟長(zhǎng)越好，每次執(zhí)行時(shí)間越短越好。

關(guān)于這幾個(gè)階段GC日志的具體內(nèi)容，可以到網(wǎng)上查找，這里就不再一一說明了。

另外，關(guān)于CMS需要關(guān)注2個(gè)JVM參數(shù)：

-XX:CMSInitiatingOccupancyFraction

-XX:+UseCMSInitiatingOccupancyOnly

1、-XX:CMSInitiatingOccupancyFraction??

老年代堆占用了多大比例時(shí)，會(huì)做一次CMS。默認(rèn)值是-1，表示不啟用。大于等于0則直接取其值，小于0則根據(jù)如下公式來計(jì)算：

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

CMSTriggerRatio在JDK1.8是80
MinHeapFreeRatio在JDK1.8是40

2、-XX:+UseCMSInitiatingOccupancyOnly

一直使用上述設(shè)定的閾值，如果不指定，JVM僅在第一次使用設(shè)定值,后續(xù)則自動(dòng)調(diào)整。

三、DefNew

意為“Default New Generation”，新生代Serial收集器中。由于用的少，就不介紹了。它打印的GC日志大概是這樣的。

[DefNew: 78656K->78656K(78656K), 0.0000398 secs]

四、一些重要的JVM參數(shù)

-Xms -XX:InitialHeapSize??? ? 堆內(nèi)存初始大小
-Xmx -XX:MaxHeapSize??????? 堆內(nèi)存最大大小???????? ?
-Xss -XX:ThreadStackSize??? 單個(gè)線程棧大小???????? ?
-XX:NewSize????????????? ? ? ? ???? 新生代初始堆大小
-XX:MaxNewSize????????????????? 新生代最大堆大小
-XX:OldSize????????????????????????? 老年代堆大小
-XX:MetaspaceSize????????????? 元數(shù)據(jù)區(qū)初始值(JDK1.8)
-XX:MaxMetaspaceSize?????? 元數(shù)據(jù)區(qū)最大值(JDK1.8)
-XX:SurvivorRatio???????????????? 用來設(shè)置新生代中eden空間和from/to空間的比例.
-XX:MaxTenuringThreshold? 對(duì)象從新生代晉升到老年代的年齡閾值，默認(rèn)值15
-XX:NewRatio?????????????????????? 老年代/新生代的堆內(nèi)存比例，在設(shè)置了-XX:MaxNewSize的情況下，-XX:NewRatio的值會(huì)被忽略

-XX:+PrintGCDateStamps
-XX:+PrintGCTimeStamps
-XX:+PrintGC
-XX:+PrintGCDetails

?使用jinfo查看進(jìn)程的JVM參數(shù)

jinfo -flags <pid>

查看JVM參數(shù)默認(rèn)值的方法

java -XX:+PrintFlagsFinal -version

?

參考文檔

GC(Allocation Failure)引發(fā)的一些JVM知識(shí)點(diǎn)梳理
https://blog.csdn.net/zc19921215/article/details/83029952
[case9]頻繁GC (Allocation Failure)及young gc時(shí)間過長(zhǎng)分析
https://segmentfault.com/a/1190000013509330
JVM常用參數(shù)說明
https://www.cnblogs.com/shjr/p/14667216.html
CMS的CMSInitiatingOccupancyFraction解析
https://blog.csdn.net/insomsia/article/details/91802923
CMS收集器幾個(gè)參數(shù)詳解 -XX:CMSInitiatingOccupancyFraction, CMSFullGCsBeforeCompaction
https://blog.csdn.net/liubenlong007/article/details/88541589
Java開發(fā)中的問題排查，性能調(diào)優(yōu)，先學(xué)會(huì)閱讀GC日志
https://cloud.tencent.com/developer/article/1478419
JVM中的垃圾收集器 -- CMS
https://blog.csdn.net/wodewutai17quiet/article/details/48895893