最近读书学习心理健康相关知识，学到了三个当下打工人常见状态概念：
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}/-
这个问题我们下一篇给探讨分析。
推荐阅读：
