JVM CMS垃圾回收器总结

Java8 默认垃圾回收器

Java 8要使用CMS(concurrent mark-sweep)，那么必须显示设置，它采用的默认垃圾回收器是ParallelGC

测试代码

package codeTest;

import java.util.ArrayList;
import java.util.List;

/**
 * @Description TestGC :
 * @Author sr
 * @Date 2021/8/29
 */
public class TestGC{

    private static final int SIZE_1M = 1024 * 1024;

    public static void main(String[] args) {
        List<byte[]> list = new ArrayList<>();
        while (true) {
            list.add(new byte[SIZE_1M]);
        }
    }
}

验证默认垃圾回收器，添加如下配置参数

-verbose:gc -XX:+PrintGCDetails

由下图可以看出，jdk8默认垃圾回收器是ParallelGC

CMS使用（concurrent mark-sweep）并发标记清除

显示申明垃圾回收器为CMS+parNew

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC

再运行以上代码可以看到现在所使用得便是CMS

堆内存大小设置 (head)

设置年轻代和老年代的大小。由于采用的CMS+ParNew。建议堆大小不要超过8G，最好6G以内，因为CMS+ParNew组合情况下发生的FGC是采用MSC算法且单线程回收，如果堆内存很大，FGC时STW（STOP THE WORLD）时间会非常恐怖。以4G举例，这时候再添加几个JVM参数。这里设置的年轻代大概是1.5G，老年代大概是2.5G。这算是一个比较合理的比例搭配。如果你的JVM参数这样搭配但是GC情况仍然不是很好，那么可能需要根据你的业务特性进行特别的调优：

-Xmx4g -Xms4g -Xmn1512m

线程栈大小设置（stack）

JDK8默认的线程栈大小为1M，有点偏大。绝大部分微服务项目是可以调整为512k，甚至256k。

-Xss512k

老年代回收阈值 (old)

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

-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly 

元数据空间 (Metaspace)

微服务架构，对于绝大部分应用来说，128M的元数据完全够用。不过，java8的元数据空间并不是指定多少就初始化多大的空间。而是按需扩展元数据空间。所以，我们可以设置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 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还不会压缩内存）

Example

推荐给大家一个搭配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

如下供查看 复制从上面

----------------------------------------------------------------------------------------------

-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/