前言哪怕JDK16 GA已经发布很久了，但是，可以肯定的是，绝大多数的生产环境依然运行的是JDK8此处必须来一句：JDK8 yyds既然运行的是JDK8，那么生产环境的垃圾回收器基本上就是下面3种啦：默认垃圾回收器
此篇文章只聚焦于如何配置一个比较合理的采用CMS作为垃圾回收器的JVM参数首先要说的是，JDK8要使用CMS，那么必须显示申明，因为它采用的默认垃圾回收器是ParallelGC如何验证它默认采用的垃圾回收器呢？非常简单，运行如下代码：。
port java.util.List; publicclassMain{
privatestaticfinalint _1M = 1024*1024; publicstaticvoidmain(String[] args){ List byteList =
new ArrayList<>(); for(int i=0; i
然后配置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，运行的棒棒哒）：。
-Xss256kOld回收阈值既然配置的是CMS，那么如下两个参数一定要加上为什么要加上这两个JVM参数呢？这是因为CMS回收条件非常复杂，如果不通过CMSInitiatingOccupancyFraction。
和UseCMSInitiatingOccupancyOnly限制只在老年代达到75%才回收的话（这个阈值可以根据具体情况适当调整），当线上碰到一些CMS GC时，是很难搞清楚原因的：-XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly
元数据空间如果是微服务架构，那么对于绝大部分应用来说，128M的元数据完全够用不过，JDK8的元数据空间并不是指定多少就初始化多大的空间而是按需扩展元数据空间所以，我们可以设置256M如果不设置这两个参数的话，元数据空间默认初始化只有20M出头，那么就会在应用启动过程中，Metaspace扩容发生FGC：。
-X
建该目录：。
收器，它采用的是标记清除算法，而不是压缩算法。
意味着随着时间的推移，碎片会越来越多，JVM终究会触发内存整理这个动作那么，什么时候整理内存碎片呢？跟下面两个参数有很大的关系第一个参数是开启这个能力，第
CMS GC不是FGC，在CMS GC搞不定的时候（比如：concurrent mode failure），会触发完
on_work(clear_all_soft_refs) } else { // mark-sweep
do_mark_sweep_work(clear_all_soft
1、CMS G
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=
/data/log/gclog/gc.
oncMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=
75 -XX:+UseCMSInitiatingOccupancy
0 -XX:+CMSClassUnloadingEnabl
最后，再介绍一个很好的校验JVM参数的网址：htt，毕竟JVM调优可不是一件简单的事情：。