JVM垃圾收集器

先看两个图：

1. Java垃圾收集器的类型：
   
2. 垃圾收集器工作的区域：
   

常见垃圾回收器

不同的垃圾回收器，适用于不同的场景。常用的垃圾回收器：

1. Serial：串行回收器是单线程的一个回收器，简单、易实现、效率高；在进行垃圾收集时候，必须暂停其他所有的工作线程直到它收集结束，新生代使用复制算法。
2. ParNew：并行回收器是Serial的多线程版，可以充分的利用CPU资源，减少回收的时间；在垃圾收集时，会Stop-the-World暂停其他所有的工作线程直到它收集结束。
3. Parallel Scavenge：吞吐量优先回收器，侧重于吞吐量的控制；新生代使用复制算法。
4. CMS：Concurrent Mark Sweep，并发标记清除回收器是一种以获取最短回收停顿时间为目标的回收器，该回收器是基于“标记-清除”算法实现的。CMS采用标记清除算法，默认并不使用标记整理算法，可能会产生很多碎片；
5. Serial old: 老年代的串行回收器，是单线程的一个回收器，采用标记-整理算法；
6. Parallel old：老年代基于吞吐量的回收器；使用多线程的标记-整理算法；
7. G1：既可以回收新生代也可以回收老年代，JDK1.9默认G1垃圾回收器。

JDK默认垃圾回收器：

1. jdk7环境下，默认使用 Parallel Scavenge（新生代）+ Serial Old（老年代）
2. jdk8环境下，默认使用 Parallel Scavenge（新生代）+ Serial Old（老年代）
3. jdk9环境下，默认使用 G1（新生代+老年代）

CMS之promotion failed&concurrent mode failure

1. promotion failed：一般是进行Minor GC的时候，发现Survivor空间不够，所以，需要移动一些新生代的对象到老年代，然而，有些时候尽管老年代有足够的空间，但是由于CMS采用标记清除算法，默认并不使用标记整理算法，可能会产生很多碎片，因此，这些碎片无法完成大对象向老年带转移，因此需要进行CMS在老年代的Full GC来合并碎片；但是Full GC导致的stop-the-wold是难以接受的。

解决方法：可以让CMS在进行一定次数的Full GC（标记清除）的时候进行一次标记整理算法，CMS提供了以下参数来控制：
-XX:UseCMSCompactAtFullCollection
-XX:CMSFullGCBeforeCompaction=5
也就是CMS在进行5次Full GC（标记清除）之后进行一次标记整理算法，从而可以控制老年代的碎片在一定的数量以内，甚至可以配置CMS在每次Full GC的时候都进行内存的整理。

2. concurrent mode failure：CMS GC线程和业务线程并发运行时业务线程将大对象放入老年代，而此时老年代空间不足；或者在做Minor GC的时候，新生代Survivor空间放不下，需要放入老年代，而老年代也放不下而产生的。此时需要尽快回收老年代里面的不再被使用的对象，停止所有的线程，同时终止CMS GC，直接进行Serial Old GC。

解决方法：
调低触发CMS GC执行的阀值，CMS GC触发主要-XX:CMSInitiatingOccupancyFraction值决定，默认情况是当旧生代已用空间为68%时，即触发CMS GC，在出现concurrent mode failure的情况下，可考虑调小这个值，提前CMS GC的触发，以保证旧生代有足够的空间。

上面二者总结一句话就是：使用标记整理清除碎片和提早进行CMS GC操作。

GC之间如何选择垃圾收集器：

CMS和G1收集器

1、CMS收集器

并行和并发概念补充：

• 并行（Parallel） ：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
• 并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行，可能会交替执行），用户程序在继续运行，而垃圾收集器运行在另一个CPU上。

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它而非常符合在注重用户体验的应用上使用；CMS收集器是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

1. 初始标记（CMS initial mark）： 暂停所有的其他线程，并记录下直接与GC Root相连的对象，速度很快（stop the world）
2. 并发标记（CMS concurrent mark）： 同时开启GC和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以GC线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
3. 重新标记（CMS remark）： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短（stop the world）
4. 并发清除（CMS concurrent sweep）： 开启用户线程，同时GC线程开始对为标记的区域做清扫。
   

CMS主要优点：并发收集、低停顿。但是它有下面三个明显的缺点：

• 对CPU资源敏感；
• 无法处理浮动垃圾；
• 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。

2、G1收集器

G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征.

被视为JDK1.7中HotSpot虚拟机的一个重要进化特征。它具备一下特点：

• 并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行
• 分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。
  空间整合：与CMS的“标记–清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的
• 可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内。

G1收集器的运作大致分为以下4个步骤：初始标记，并发标记，最终标记，筛选回收

G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了GF收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。

怎么选择垃圾收集器？

1. 优先调整堆的大小让服务器自己来选择
2. 如果内存小于100m，使用串行收集器
3. 如果是单核，并且没有停顿时间的要求，串行或JVM自己选择
4. 如果允许停顿时间超过1秒，选择并行或者JVM自己选
5. 如果响应时间最重要，并且不能超过1秒，使用并发收集器

官方推荐G1，性能高。

参考链接：CMS之promotion failed&concurrent mode failure，G1垃圾收集器，GC之7大垃圾收集器详解，深入浅出CMS垃圾收集器