哪怕JDK16 GA已經(jīng)發(fā)布很久了，但是，可以肯定的是，絕大多數(shù)的生產(chǎn)環(huán)境依然運(yùn)行的是JDK8。此處必須來一句：JDK8 yyds。既然運(yùn)行的是JDK8，那么生產(chǎn)環(huán)境的垃圾回收器基本上就是下面3種啦：
- PS（JDK8默認(rèn)）
- CMS
- G1
默認(rèn)垃圾回收器
筆者此篇文章只聚焦于如何配置一個(gè)比較合理的采用CMS作為垃圾回收器的JVM參數(shù)。首先要說的是，JDK8要使用CMS，那么必須顯示申明，因?yàn)樗捎玫哪J(rèn)垃圾回收器是ParallelGC。如何驗(yàn)證它默認(rèn)采用的垃圾回收器呢?非常簡單，運(yùn)行如下代碼：
- package com.afei.test.main;
- import java.util.ArrayList;
- import java.util.List;
- /**
- * @author 公眾號(hào): 阿飛的博客
- */
- public class Main {
- private static final int _1M = 1024*1024;
- public static void main(String[] args) {
- List<byte[]> byteList = new ArrayList<>();
- for(int i=0; i<Integer.MAX_VALUE; i++){
- byte[] test = new byte[_1M];
- byteList.add(test);
- }
- }
- }
然后配置JVM參數(shù)：
- -verbose:gc -XX:+PrintGCDetails
運(yùn)行幾秒鐘后，我們強(qiáng)行停止JVM進(jìn)程，就會(huì)在控制臺(tái)中看到如下日志從而佐證JDK8采用的默認(rèn)垃圾回收器就是ParallelGC：
- [Full GC (Allocation Failure) [PSYoungGen: 342021K->342021K(348672K)] [ParOldGen: 1397423K->1397406K(1398272K)] 1739445K->1739427K(1746944K), [Metaspace: 3357K->3357K(1056768K)], 0.1902415 secs] [Times: user=0.26 sys=0.01, real=0.19 secs]
或者可以通過如下信息得知默認(rèn)垃圾回收器為ParallelGC：圖片
CMS用法
接下來筆者從多個(gè)方面介紹如何配置一個(gè)較好的使用CMS垃圾回收器的JVM參數(shù)參數(shù)。
顯示申明CMS
顯示申明垃圾回收器為CMS+parNew非常簡單，只需要添加如下兩個(gè)JVM參數(shù)：
- -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
這時(shí)候，再運(yùn)行上面的代碼，就會(huì)得到如下信息。由下圖可知，這時(shí)候年輕代采用的是ParNew，而老年代采用的是CMS(concurrent mark-sweep)：
顯示申明CMS只是使用CMS的第一步，接下來還有很多優(yōu)化需要我們?nèi)プ觯€有很多JVM參數(shù)等待我們?nèi)ヅ渲谩?/p>
堆大小
接下來，最重要的就是申明年輕代和老年代的大小。由于采用的CMS+ParNew。建議堆大小不要超過8G，最好6G以內(nèi)，因?yàn)镃MS+ParNew組合情況下發(fā)生的FGC是采用MSC算法且單線程回收，如果堆內(nèi)存很大，F(xiàn)GC時(shí)STW時(shí)間會(huì)非常恐怖。筆者這里以4G舉例，這時(shí)候再添加幾個(gè)JVM參數(shù)，我們得到如下的配置。這里筆者設(shè)置的年輕代大概是1.5G，老年代大概是2.5G。這算是一個(gè)比較合理的比例搭配。如果你的JVM參數(shù)這樣搭配但是GC情況仍然不是很好，那么可能需要根據(jù)你的業(yè)務(wù)特性進(jìn)行特別的調(diào)優(yōu)：
- -Xmx4g -Xms4g -Xmn1512m
線程棧
JDK8默認(rèn)的線程棧大小為1M，有點(diǎn)偏大。以筆者的經(jīng)驗(yàn)，絕大部分微服務(wù)項(xiàng)目是可以調(diào)整為512k，甚至256k的(筆者的項(xiàng)目就是256k，運(yùn)行的棒棒噠)：
- -Xss256k
Old回收閾值
既然配置的是CMS，那么如下兩個(gè)參數(shù)一定要加上。為什么要加上這兩個(gè)JVM參數(shù)呢?這是因?yàn)镃MS回收條件非常復(fù)雜，如果不通過CMSInitiatingOccupancyFraction和UseCMSInitiatingOccupancyOnly限制只在老年代達(dá)到75%才回收的話(這個(gè)閾值可以根據(jù)具體情況適當(dāng)調(diào)整)，當(dāng)線上碰到一些CMS GC時(shí)，是很難搞清楚原因的：
- -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly
CMS GC觸發(fā)條件相關(guān)文章推薦--【JVM 源碼解讀之 CMS GC 觸發(fā)條件】：https://mp.weixin.qq.com/s/Mu-Xz4CLgdxJhcMJ7aKAHg
元數(shù)據(jù)空間
如果是微服務(wù)架構(gòu)，那么對(duì)于絕大部分應(yīng)用來說，128M的元數(shù)據(jù)完全夠用。不過，JDK8的元數(shù)據(jù)空間并不是指定多少就初始化多大的空間。而是按需擴(kuò)展元數(shù)據(jù)空間。所以，我們可以設(shè)置256M。如果不設(shè)置這兩個(gè)參數(shù)的話，元數(shù)據(jù)空間默認(rèn)初始化只有20M出頭，那么就會(huì)在應(yīng)用啟動(dòng)過程中，Metaspace擴(kuò)容發(fā)生FGC：
- -XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256M
dump路徑
設(shè)定如下兩個(gè)參數(shù)(需要說明的是，HeapDumpPath參數(shù)指定的路徑需要提前創(chuàng)建好，JVM沒辦法在生成dump文件時(shí)創(chuàng)建該目錄)，當(dāng)JVM內(nèi)存導(dǎo)致導(dǎo)致JVM進(jìn)程退出時(shí)能自動(dòng)在該目錄下生成dump文件：
- -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/log/jvmdump/
GC日志
這個(gè)必須有，不然線上環(huán)境GC問題都不好排查。并且loggc所在目錄(/data/log/gclog/)和dump路徑一樣，必須提前創(chuàng)建好，JVM無法自動(dòng)創(chuàng)建該目錄：
- -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/log/gclog/gc.log
壓縮
我們都知道，CMS GC是并發(fā)的垃圾回收器，它采用的是標(biāo)記清除算法，而不是壓縮算法。意味著隨著時(shí)間的推移，碎片會(huì)越來越多，JVM終究會(huì)觸發(fā)內(nèi)存整理這個(gè)動(dòng)作。那么，什么時(shí)候整理內(nèi)存碎片呢?跟下面兩個(gè)參數(shù)有很大的關(guān)系。第一個(gè)參數(shù)是開啟這個(gè)能力，第二個(gè)參數(shù)表示在壓縮(compaction)內(nèi)存之前需要發(fā)生多少次不壓縮內(nèi)存的FGC。CMS GC不是FGC，在CMS GC搞不定的時(shí)候(比如：concurrent mode failure)，會(huì)觸發(fā)完全STW但不壓縮內(nèi)存的FGC(假定命名為NoCompactFGC)，或者觸發(fā)完全STW并且壓縮內(nèi)存的FGC(假定命名為CompactFGC)。所以，這個(gè)參數(shù)的意思就是，連續(xù)多少次NoCompactFGC后觸發(fā)CompactFGC。如果中間出現(xiàn)了CMS GC，那么又需要重新計(jì)數(shù)NoCompactFGC發(fā)生的次數(shù)：
- -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0
CMS回收條件推薦文章--[JVM 源碼解讀之 CMS 何時(shí)會(huì)進(jìn)行 Full GC]：https://mp.weixin.qq.com/s/zn3-9e7ZZ7skLo1XDL0xww
筆者這里給出的配置事實(shí)上是默認(rèn)值，即每次CMS GC搞不定的情況下觸發(fā)CompactFGC。這兩個(gè)參數(shù)很不好理解，為此，筆者舉幾個(gè)例子，假定有3種GC方式：CMS GC，NoCompactFGC， CompactFGC(如下時(shí)yi du a)：
- if(should_compact){
- // mark-sweep-compact
- do_compaction_work(clear_all_soft_refs)
- } else {
- // mark-sweep
- do_mark_sweep_work(clear_all_soft_refs,first_state,should_start_over);
- }
NoCompactFGC就是不壓縮內(nèi)存的FGC，采用的是標(biāo)記清除(Mark-Sweep)算法，CompactFGC是會(huì)壓縮內(nèi)存的FGC，采用的是標(biāo)記清除壓縮算法(Mark Sweep Compact)，然后假設(shè)我們配置了-XX:CMSFullGCsBeforeCompaction=3，那么：
- 1、CMS GC, NoCompactFGC, NoCompactFGC, NoCompactFGC, CompactFGC（這時(shí)候如果發(fā)生FGC就會(huì)壓縮內(nèi)存）
- 2、CMS GC, NoCompactFGC, NoCompactFGC, CMS GC, NoCompactFGC（這時(shí)候如果發(fā)生FGC不會(huì)壓縮內(nèi)存，因?yàn)樵诖酥安]有連續(xù)3次NoCompactFGC）
- 3、CMS GC, CMS GC, CMS GC, NoCompactFGC（如果前面連續(xù)發(fā)生的是CMS GC，那么接下來觸發(fā)的FGC還不會(huì)壓縮內(nèi)存）
one more
最后，再推薦給大家一個(gè)搭配CMS時(shí)很好用的JVM參數(shù)，如下所示。官方對(duì)該參數(shù)的說明為:A System.gc() request invokes a concurrent collection and also unloads classes during such a concurrent gc cycle (effective only when UseConcMarkSweepGC)。這句話總結(jié)如下：1、只有在使用CMS時(shí)才有效。2、當(dāng)調(diào)用System.gc()時(shí)會(huì)用CMS這個(gè)并行垃圾回收器去進(jìn)行回收(比如大量使用DirectByteBuffer進(jìn)行堆外內(nèi)存操作，需要FGC來回收堆外內(nèi)存的場(chǎng)景。就可以通過該參數(shù)讓本來需要FGC才能搞定的事情用CMS GC就可以搞定了)。3、除了能喚起并行垃圾回收器，還能卸載類。
- -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
最終，得到我們配置的完整的JVM參數(shù)配置如下(此參數(shù)在以前筆者負(fù)責(zé)的一個(gè)微服務(wù)項(xiàng)目中運(yùn)行了數(shù)年，單機(jī)并發(fā)1000+，CMS GC大概是8天左右一次)：
- -Xms4g -Xmx4g -Xmn1512m -server -Xss256k -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256m -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/log/gclog/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/log/jvmdump/ -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:+TieredCompilation -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
最后，筆者再介紹一個(gè)很好的校驗(yàn)JVM參數(shù)的網(wǎng)址：https://opts.console.heapdump.cn/，這里我們可以用到它的“參數(shù)檢查”。不過需要說明的是：盡信書不如不讀書，此網(wǎng)址的校驗(yàn)結(jié)果只是作為參考，是否完全符合你的生產(chǎn)環(huán)境，還得視情況而定，畢竟JVM調(diào)優(yōu)可不是一件簡單的事情：
原文鏈接：https://mp.weixin.qq.com/s/fECbisbcIqVRaIxfLKM6ew
