CMS用法

1、查看JVM垃圾回收器类别，默认：ParallelGC

VM options：-XX:+PrintGCDetails 

-XX:+PrintGCDetails

日志输出如下： 

 GC日志中展示PSYoungGen、ParOldGen则垃圾回收期为ParallelGC

配置CMS垃圾回收器参数如下

VM options参数：-XX:+PrintGCDetails -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

-XX:+PrintGCDetails -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

年轻代袋采用 ParNew，老年代采用CMS（concurrent mark-sweep）

 GC日志输出如下：

 

堆大小

        最重要的是声明年轻代和老年代的大小，由于采用的是CMS+ParNew，建议堆大小不要超过8G，最好6G以内，因为CMS+ParNew组合情况下发生的FGC是采用MSC算法且单线程回收，如果堆内存河大，FGC在STW时间会非常恐怖，这里以4G举例，再添加介个JVM参数，年轻代大概1.5G，老年代大概2.5G，算是一个合理的搭配比例，如果这些参数搭配，GC情况仍然不是很好，那么就需要进行特殊业务属性进行特别调优：

-Xmx4g -Xms4g -Xmn1512m

线程栈

JDK8默认线程栈大小为1M，有点偏大，以我的经验，绝大多数微服务项目可以调整为512K，甚至256K

-Xss256k

Old回收阈值

既然垃圾回收器配置是CMS，需要加上如下两个参数，至于为什么要加上这两个参数，是因为CMS回收条件非常复杂，如果不通过CMSInitiatingOccupancyFraction和UseCMSInitiatingOccupancyOnly限制只有在老年代达到75%才回收（这个阈值可以根据业务具体适当调整），当线上碰到一些CMS GC时，是很难搞清楚原因的：

-XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly 

 元数据空间

如果是微服务架构，对绝大多数应用来说，128M的元数据完全够用，不过JDK8的元数据空间并不是指定多少就初始化多大的空间，而是按需扩展元数据空间，所以我们可以设置256M，如果不设置这两个参数，元数据空间默认初始化只有20M出头，那么就会在应用启动过程，Metaspace扩容发生FGC:

-XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256M

dump路径

设置如下两个参数（需要说明的是，HeapDumpPath参数指定的路径需要提前创建好，JVM无法自动创建该目录），当JCM内存导致JVM进程退出时能自动在该目录下生成dump文件：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/log/jvmdump/

GC日志

这个必须有，不然线上环境GC问题不好排查，并且loggc所在目录（/data/log/gclog/）和dump路径一样，必须提前创建和，JVM无法自动创建该目录：

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/log/gclog/gc.log

压缩

CMS GC是并发的垃圾回收器，采用的是标记清除算法，而不是压缩算法，随着时间的推移，碎片会越来越多，JVM终究会触发内存整理这个操作，那么什么时候整理内存碎片呢？和下面两个参数关系很大。第一个参数是开启这个内里，第二个参数表示在压缩（compaction）内存之前需要发生多少次不压缩内存的FGC， CMS GC不是FGC，在CMS GC搞不定的时候（比如：concurrent mode failure），会触发完全STW但不压缩内存的FGC（假定命名为NoCompactFGC）,或者触发完全STW并且压缩内存的FGC（假定命名为CompactFGC），所以这个参数的意思是，连续多少次NoCompactFGC后触发CompactFGC，如果中间出现了CMS GC，那么又需要重新计算NoCompactFGC发生的次数：

-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0

我这里配置的是默认值，即每次CMS GC搞不定的情况下，触发CompactFGC。

NoCompactFGC就是不压缩内存的FGC，采用标记清除算法（Mark-Sweep），

CompactFGC就是会压缩内存的FGC，采用标记清除压缩算法（Mark-Sweep Compact），假设我们配置了-XX:CMSFullGCsBeforeCompaction=3

1、CMS GC, NoCompactFGC, NoCompactFGC, NoCompactFGC, CompactFGC（这时候如果发生FGC就会压缩内存）
2、CMS GC, NoCompactFGC, NoCompactFGC, CMS GC, NoCompactFGC（这时候如果发生FGC不会压缩内存，因为在此之前并没有连续3次NoCompactFGC）
3、CMS GC, CMS GC, CMS GC, NoCompactFGC（如果前面连续发生的是CMS GC，那么接下来触发的FGC还不会压缩内存）

最终我们配置的完整JVM参数配置如下：

-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

最后分享一个很好的校验JVM参数的网址：https://opts.console.heapdump.cn/，我们可以用到它的"参数检查"。这里只是做为参考，不同的业务需要不同的特殊配置，毕竟JVM调优可不是一件简单的事情。

-server -Xmx10880M -Xms10880M -Xss256k -Xloggc:/data/log/gclog/gc.log -XX:+UseParNewGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/log/jvmdump/ -XX:+TieredCompilation -XX:MaxMetaspaceSize=512M -XX:MetaspaceSize=512M -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+ParallelRefProcEnabled