JVM进阶调优系列(5)CMS回收器通俗演义一文讲透FullGC

最近读书学习心理健康相关知识，学到了三个当下打工人常见状态概念：

1、悲伤、抑郁、焦虑，分别制造了过去之熵，现在之熵、未来之熵。心理情绪熵减调理，需要解决掉这些负熵。

JVM的调优，重中之中就是FullGC的优化。FullGC由于Stop the world耗时大，快的的几秒，慢的几十秒，对业务的正常运行造成了负面影响。本文主角CMS垃圾回收器在对FullGC做了充足的优化，值得深入探讨学习。

一、让人头疼的Stop the world

Stop the world发生后，jvm程序的全部线程暂停运行，不能创建对象，让垃圾回收器专注清理垃圾对象。此时我们的接口响应被迫延迟，最终传导影响业务客户系统丝滑体验。在G1回收器出现之前，这个stop the world一直是JVM的最大痛点。

二、什么时候会触发FullGC？

YGC也会stop the world，只是YGC耗时短，影响不明显。这里不赘述YGC的时机，之前文章已分享过，这里详细分析FullGC触发时机。

2.1 空间担保机制

JDK8默认是开启。具体就是如果当前老年代可用空间小于年轻代全部对象的大小，由于有空间担保机制，不会马上发生Full GC，而会再看看其他条件。如果没有空间担保机制，就会马上发生Full GC。

2.2 比较历次YGC存活进入老年代的平均对象大小

当前老年代可用空间小于历次YGC后进入老年代的平均对象大小，会发生Full GC。

2.3 比较老年代可用空间

YGC存活的对象过大，S区存放不小，而且老年代可用空闲空间也不放心，就发生Full GC。

2.4 检查-XX:CMSInitiatingOccupancyFaction参数

这个值默认是92%。如果配置该参数即使老年代可用空间大于历次YGC后进入老年代的平均对象大小，但是当前老年代占用大于92%空间，CMS垃圾回收器也会进行FullGC。配这个参数的好处在于，老年代有预留的8%空间，让JVM在CMS并发回收期间，系统还可以继续把一些新对象存入老年代。

三、为什么Full GC慢？

这个之前有分享过，就是并发整理过程比较慢，涉及GC roots追踪对象，以及内存碎片整理。这两个过程很复杂，然后关于内存碎片整理，有2个参数有必要说一下。

3.1 -XX:+UseCMSCompactAtFullCollection

默认是打开。顾名思义这个参数的作用就是用来做内存碎片整理。具体就是CMS 完成Full GC后，再次进行stop the world，然后将存活对象挪到一起，空出来一片连续内存，避免内存碎片。

3.2 -XX:+CMSFullGCCsBeforeCompaction

CMS垃圾回收器Full GC多少次后才开始做内存碎片整理，默认就是0，意味着每次FGC后都整理碎片。这个是官方推荐，也是比较合适的。如果设置为5，就是5次Full GC后才进行内存碎片整理，会导致老年代在前5次Full GC后有比较多的内存碎片，这个参数需要慎重考虑优化配置。

那导致Full GC慢的另一个原因：GC roots追踪，又是什么呢？

四、GC roots是什么？

GC Roots是垃圾收集器可以访问的引用对象，通过这些对象可以找到其他所有可达的对象。比如：虚拟机栈中的对象引用（典型的局部变量、方法里new实例对象名地址）：之前文章说过每个线程都有一个私有的Java虚拟机栈，该线程执行每个方法的调用执行，都会将一个栈帧在线程的虚拟机栈中入栈出栈。如果一个变量、或实例对象在方法执行过程中被引用，则该对象可以作为GC Roots，以及static修饰的类静态变量都是GC Roots。具体还有很多这里不赘述。

五、对对象进行GC Roots追踪和GC roots标记有啥区别？

GC roots标记，就是遍历GC roots，看看他们引用的对象是哪些。也就是通过GC roots根对象引用，去找具体对象。而【对象进行GC Roots追踪】，刚好相反。这是通过遍历全部对象，然后看看每个对象是否有对应GC roots引用。

理解了这两点，一会看CMS的四阶段GC处理就很方便。

六、CMS垃圾回收器处理FGC的四个阶段

6.1 初始标记

首先stop the world，系统的工作线程全部暂停。CMS开始初始标记，这个阶段就是标记出所有GC roots引用的对象。虽然导致代码程序暂停，但是CMS的垃圾回收是多个回收线程并发执行，默认回收线程数量=（系统cpu核数+3）/4，标记效率很高，这个阶段对系统几乎无感影响。

比如以下代码，执行到方法gcRootsHere()的System.out.println发生了FGC，那初始阶段就是回收线程，在老年代区域根据类静态变量name，userA,还有和法局部变量user的地址引用，去把这些GC roots引用的对象标记出来。

public class Demo002JvmShow {
    public static final String name = "我是类静态变量";
    public static User userA = new User("A");
    private Object object = new Object();
    private boolean isOk = 10 / 2 == 4 ? true : false;
    public void gcRootsHere(){
        int a = 5;
        User user = new User("我是实例对象，我有GC roots引用我，不许回收我");
        System.out.println("线程执行到这里，发送了FullGC .....");
    }

6.2 并发标记

这个阶段，运行程序从暂停状态stop the world 变成继续运行，以及继续做标记。这个阶段些微复杂一些，因为这时候系统继续运行，肯定就会产生新的对象，也有的对象变成了垃圾对象。回收线程，这时候的标记和阶段1【初始标记】有所不同。这时候是对老年代所有对象进行GC roots追踪。什么意思呢？

就是遍历老年代的对象，看看这个对象被谁引用，一级级往上找，看最终是否有被GC roots引用。这个是不是有点意思，和初始标记反着来？一个是从上往下，一个是从下往上。

这个阶段非常耗时，一个是因为老年代发生FGC说明老年代对象很多，另外一个就是追踪链路很长，一层层去追踪，向上找是否有被GC roots引用。如果没有被引用就是垃圾对象，一会可以回收。

虽然很耗时，但是好在是程序恢复了继续运行，也就影响不大。

6.3 重新标记

并发标记结束后，由于程序恢复运行，产生了很多新对象，最重要的是有很多对象在这期间变成了垃圾对象，这时候就需要重新标记把他们标出来，也一并回收。

重新标记阶段，采用的是stop the world，这样就可以避免有新垃圾产生，彻底标记垃圾对象。

这个阶段，运行也是非常快，原因是只对阶段二程序继续运行影响到的对象进行标记，这个数量肯定是比较少。所以这次stop the world也影响不大。看完这里，不得不佩服CMS的优秀设计，对FGC的优化真是做到极致。

6.4 并发清理

经历了【初始标记】【并发标记】【重新标记】三个阶段标记，所有垃圾对象都标记出来，那开始做清理了。

这个阶段，竟然是并发，就是允许程序工作线程恢复运行。系统一边运行，CMS垃圾回收器对垃圾对象进行回收整理。这个阶段实际是非常耗时，比如整理碎片，整理存活对象。但是因为程序可以继续运行，那影响也很小。

七、正在进行FullGC，老年代放不下程序产生的新对象就会直接OOM了吗？

我们知道在【并发清理】这个期间，程序是可以正常运行的。原因是老年代在回收碎片，程序依然可以继续往里面放新对象。此时如果系统要往老年代放新对象，放不下（为啥会往老年代放新对象？这个看过前几篇的文章同学就知道，有些对象是可以直接进老年代的），这时候会发生Concurrent mode failure，而不是OOM。这时候JVM自动使用Serial Old垃圾回收器替换CMS回收器，强行让程序stop the word，程序暂停运行，不允许新对象生成。直到GC完成后再恢复。

八、看看这份JVM调优入参，分别代表什么？

-Xmx4096, -Xms2048,  -Xmn2048 -Xss2m -XX:SurvivorRatio=8 
-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=512m
 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC 
 XX:MaxTenuringThreshold=10  -XX:CMSInitiatingOccupancyFaction 
 -XX:+PrintGC  -XX:+HeapDumpOnOutOfMemoryError 
 -XX:HeapDumpPath=${LOGDIR}/-

这个问题我们下一篇给探讨分析。

推荐阅读：

1、JVM进阶调优系列(3)堆内存的对象什么时候被回收?

2、JVM进阶调优系列(2)字节面试:JVM内存区域怎么划分，分别有什么用？

3、JVM进阶调优系列(1)类加载器原理一文讲透

4、JAVA并发编程系列(13)Future、FutureTask异步小王子