哪怕JDK16 GA如故发布很深刻，然而，不错确定的是，绝大多数的分娩环境依然运行的是JDK8。此处必须来一句：JDK8 yyds。既然运行的是JDK8，那么分娩环境的垃圾回收器基本上便是底下3种啦：

PS（JDK8默许） CMS G1 默许垃圾回收器

笔者此篇著作只聚焦于如何竖立一个比拟合理的招揽CMS动作垃圾回收器的JVM参数。最初要说的是，JDK8要使用CMS，那么必须真切声名，因为它招揽的默许垃圾回收器是ParallelGC。如何考证它默许招揽的垃圾回收器呢?相配肤浅，运行如下代码：

package com.afei.test.main;  import java.util.ArrayList; import java.util.List;  /**  * @author 公众号: 阿飞的博客  */ 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参数：

-verbose:gc -XX:+PrintGCDetails 

运行几秒钟后，咱们强行罢手JVM进度，就会在戒指台中看到如下日记从而佐证JDK8招揽的默许垃圾回收器便是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]  

或者不错通过如下信息得知默许垃圾回收器为ParallelGC：图片

CMS用法

接下来笔者从多个方面先容如何竖立一个较好的使用CMS垃圾回收器的JVM参数参数。

真切声名CMS

真切声名垃圾回收器为CMS+parNew相配肤浅，只需要添加如下两个JVM参数：

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC 

这工夫，再运行上头的代码，就会获得如下信息。由下图可知，这工夫年青代招揽的是ParNew，而老年代招揽的是CMS(concurrent mark-sweep)：

真切声名CMS仅仅使用CMS的第一步，接下来还有好多优化需要咱们去做，还有好多JVM参数恭候咱们去竖立。

堆大小

接下来，最进攻的便是申来岁青代和老年代的大小。由于招揽的CMS+ParNew。提议堆大小不要越过8G，最佳6G以内，因为CMS+ParNew组合情况下发生的FGC是招揽MSC算法且单线程回收，要是堆内存很大，FGC时STW时辰会相配恐怖。笔者这里以4G例如，这工夫再添加几个JVM参数，咱们获得如下的竖立。这里笔者建立的年青代大要是1.5G，老年代大要是2.5G。这算是一个比拟合理的比例搭配。要是你的JVM参数这么搭配然而GC情况仍然不是很好，那么可能需要把柄你的业务特点进行卓越的调优：

-Xmx4g -Xms4g -Xmn1512m 

线程栈

JDK8默许的线程栈大小为1M，有点偏大。以笔者的教授，绝大部分微办事神色是不错调度为512k，以致256k的(笔者的神色便是256k，运行的棒棒哒)：

-Xss256k 

Old回收阈值

既然竖立的是CMS，那么如下两个参数一定要加上。为什么要加上这两个JVM参数呢?这是因为CMS回收据件相配复杂，要是欠亨过CMSInitiatingOccupancyFraction和UseCMSInitiatingOccupancyOnly升天只在老年代达到75%才回收的话(这个阈值不错把柄具体情况稳健调度)，当线上遭遇一些CMS GC时，是很难搞明晰原因的：

-XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly 

CMS GC触发条款臆测著作保举--【JVM 源码解读之 CMS GC 触发条款】：https://mp.weixin.qq.com/s/Mu-Xz4CLgdxJhcMJ7aKAHg

元数据空间

要是是微办事架构，那么关于绝大部分运用来说，128M的元数据总共够用。不外，JDK8的元数据空间并不是指定几许就开动化多大的空间。而是按需延长元数据空间。是以，咱们不错建立256M。要是不建立这两个参数的话，元数据空间默许开动化只须20M出面，那么就会在运用启动经由中，Metaspace扩容发生FGC：

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

dump旅途

设定如下两个参数(需要证实的是，HeapDumpPath参数指定的旅途需要提前创建好，JVM没主义在生成dump文献时创建该目次)，当JVM内存导致导致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回收据件保举著作--[JVM 源码解读之 CMS 何时会进行 Full GC]：https://mp.weixin.qq.com/s/zn3-9e7ZZ7skLo1XDL0xww

笔者这里给出的竖立事实上是默许值，即每次CMS GC搞不定的情况下触发CompactFGC。这两个参数很不好合资，为此，笔者举几个例子，假设有3种GC面貌：CMS GC，NoCompactFGC， CompactFGC(如下时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便是不压缩内存的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还不会压缩内存） 

one more

临了，再保举给各人一个搭配CMS时很好用的JVM参数，如下所示。官方对该参数的证实为:A System.gc() request invokes a concurrent collection and also unloads classes during such a concurrent gc cycle (effective only when UseConcMarkSweepGC)。这句话回想如下：1、只须在使用CMS时才有用。2、当调用System.gc()时会用CMS这个并行垃圾回收器去进行回收(比如大都使用DirectByteBuffer进行堆外内存操作，需要FGC往复收堆外内存的场景。就不错通过该参数让原来需要FGC才能责罚的事情用CMS GC就不错责罚了)。3、除了能唤起并行垃圾回收器，还能卸载类。

-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses 

最终，获得咱们竖立的齐备的JVM参数竖立如下(此参数在畴昔笔者厚爱的一个微办事神色中运行了数年，单机并发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 

临了，笔者再先容一个很好的校验JVM参数的网址：https://opts.console.heapdump.cn/，这里咱们不错用到它的“参数搜检”。不外需要证实的是：尽信书不如不念书，此网址的校验成果仅仅动作参考，是否总共相宜你的分娩环境，还得视情况而定，毕竟JVM调优可不是一件肤浅的事情：

 本文转载自微信公众号「阿飞的博客」，不错通过以下二维码关爱。转载本文请臆测阿飞的博客公众号。