CMS & G1

CMS垃圾收集器的原理

CMS收集器和G1收集器的优缺点

CMS垃圾收集器的原理

图解 CMS 垃圾回收机制原理，-阿里面试题

G1 垃圾收集器 参考：G1 垃圾收集器入门

G1 与CMS的区别 参考：CMS收集器和G1收集器优缺点

什么是CMS

CMS全称 ConcurrentMarkSweep，是一款并发的、使用标记-清除算法的垃圾回收器， 如果老年代使用CMS垃圾回收器，需要添加虚拟机参数-"XX:+UseConcMarkSweepGC"。

使用场景：

GC过程短暂停，适合对时延要求较高的服务，用户线程不允许长时间的停顿。

缺点：

服务长时间运行，造成严重的内存碎片化。 另外，算法实现比较复杂（如果也算缺点的话）

实现机制

根据GC的触发机制分为：周期性Old GC（被动）和主动Old GC，纯属个人理解，实在不知道怎么分才好。

周期性Old GC

周期性Old GC，执行的逻辑也叫 BackgroundCollect，对老年代进行回收，在GC日志中比较常见，由后台线程ConcurrentMarkSweepThread循环判断（默认2s）是否需要触发。

触发条件

1. 如果没有设置 UseCMSInitiatingOccupancyOnly，虚拟机会根据收集的数据决定是否触发（线上环境建议带上这个参数，不然会加大问题排查的难度）
2. 老年代使用率达到阈值 CMSInitiatingOccupancyFraction，默认92%
3. 永久代的使用率达到阈值 CMSInitiatingPermOccupancyFraction，默认92%，前提是开启 CMSClassUnloadingEnabled
4. 新生代的晋升担保失败

晋升担保失败

老年代是否有足够的空间来容纳全部的新生代对象或历史平均晋升到老年代的对象，如果不够的话，就提早进行一次老年代的回收，防止下次进行YGC的时候发生晋升失败。

周期性Old GC过程

当条件满足时，采用“标记-清理”算法对老年代进行回收，过程可以说很简单，标记出存活对象，清理掉垃圾对象，但是为了实现整个过程的低延迟，实际算法远远没这么简单，整个过程分为如下几个部分：

对象在标记过程中，根据标记情况，分成三类：

1. 白色对象，表示自身未被标记；
2. 灰色对象，表示自身被标记，但内部引用未被处理；
3. 黑色对象，表示自身被标记，内部引用都被处理；

假设发生Background Collect时，Java堆的对象分布如下：

1、InitialMarking（初始化标记，整个过程STW）

该阶段单线程执行，主要分分为两步：

1. 标记GC Roots可达的老年代对象；
2. 遍历新生代对象，标记可达的老年代对象；

该过程结束后，对象分布如下：

2、Marking（并发标记）

该阶段GC线程和应用线程并发执行，遍历InitialMarking阶段标记出来的存活对象，然后继续递归标记这些对象可达的对象。

因为该阶段并发执行的，在运行期间可能发生新生代的对象晋升到老年代、或者是直接在老年代分配对象、或者更新老年代对象的引用关系等等，对于这些对象，都是需要进行重新标记的，否则有些对象就会被遗漏，发生漏标的情况。

为了提高重新标记的效率，该阶段会把上述对象所在的Card标识为Dirty，后续只需扫描这些Dirty Card的对象，避免扫描整个老年代。

3、Precleaning（预清理）

通过参数 CMSPrecleaningEnabled选择关闭该阶段，默认启用，主要做两件事情：

1. 处理新生代已经发现的引用，比如在并发阶段，在Eden区中分配了一个A对象，A对象引用了一个老年代对象B（这个B之前没有被标记），在这个阶段就会标记对象B为活跃对象。
2. 在并发标记阶段，如果老年代中有对象内部引用发生变化，会把所在的Card标记为Dirty（其实这里并非使用CardTable，而是一个类似的数据结构，叫ModUnionTalble），通过扫描这些Table，重新标记那些在并发标记阶段引用被更新的对象（晋升到老年代的对象、原本就在老年代的对象）

4、AbortablePreclean（可中断的预清理）

该阶段发生的前提是，新生代Eden区的内存使用量大于参数CMSScheduleRemarkEdenSizeThreshold默认是2M，如果新生代的对象太少，就没有必要执行该阶段，直接执行重新标记阶段。

为什么需要这个阶段，存在的价值是什么？

因为CMS GC的终极目标是降低垃圾回收时的暂停时间，所以在该阶段要尽最大的努力去处理那些在并发阶段被应用线程更新的老年代对象，这样在暂停的重新标记阶段就可以少处理一些，暂停时间也会相应的降低。

在该阶段，主要循环的做两件事：

1. 处理 From 和 To 区的对象，标记可达的老年代对象
2. 和上一个阶段一样，扫描处理Dirty Card中的对象

当然了，这个逻辑不会一直循环下去，打断这个循环的条件有三个：

1. 可以设置最多循环的次数 CMSMaxAbortablePrecleanLoops，默认是0，表示没有循环次数的限制。
2. 如果执行这个逻辑的时间达到了阈值 CMSMaxAbortablePrecleanTime，默认是5s，会退出循环。
3. 如果新生代Eden区的内存使用率达到了阈值 CMSScheduleRemarkEdenPenetration，默认50%，会退出循环。（这个条件能够成立的前提是，在进行Precleaning时，Eden区的使用率小于十分之一）

如果在循环退出之前，发生了一次YGC，对于后面的Remark阶段来说，大大减轻了扫描年轻代的负担，但是发生YGC并非人为控制，所以只能祈祷这5s内可以来一次YGC。

1. ...
2. 1678.150:[CMS-concurrent-preclean-start]
3. 1678.186:[CMS-concurrent-preclean:0.044/0.055secs]
4. 1678.186:[CMS-concurrent-abortable-preclean-start]
5. 1678.365:[GC 1678.465:[ParNew:2080530K->1464K(2044544K),0.0127340secs]
6. 1389293K->306572K(2093120K),
7. 0.0167509secs]
8. 1680.093:[CMS-concurrent-abortable-preclean:1.052/1.907secs]
9. ....

在上面GC日志中，1678.186启动了AbortablePreclean阶段，在随后不到2s就发生了一次YGC。

5、FinalMarking（并发重新标记，STW过程）

该阶段并发执行，在之前的并行阶段（GC线程和应用线程同时执行，好比你妈在打扫房间，你还在扔纸屑），可能产生新的引用关系如下：

1. 老年代的新对象被GC Roots引用
2. 老年代的未标记对象被新生代对象引用
3. 老年代已标记的对象增加新引用指向老年代其它对象
4. 新生代对象指向老年代引用被删除
5. 也许还有其它情况..

上述对象中可能有一些已经在Precleaning阶段和AbortablePreclean阶段被处理过，但总存在没来得及处理的，所以还有进行如下的处理：

1. 遍历新生代对象，重新标记
2. 根据GC Roots，重新标记
3. 遍历老年代的Dirty Card，重新标记，这里的Dirty Card大部分已经在clean阶段处理过

在第一步骤中，需要遍历新生代的全部对象，如果新生代的使用率很高，需要遍历处理的对象也很多，这对于这个阶段的总耗时来说，是个灾难（因为可能大量的对象是暂时存活的，而且这些对象也可能引用大量的老年代对象，造成很多应该回收的老年代对象而没有被回收，遍历递归的次数也增加不少），如果在AbortablePreclean阶段中能够恰好的发生一次YGC，这样就可以避免扫描无效的对象。

如果在AbortablePreclean阶段没来得及执行一次YGC，怎么办？

CMS算法中提供了一个参数： CMSScavengeBeforeRemark，默认并没有开启，如果开启该参数，在执行该阶段之前，会强制触发一次YGC，可以减少新生代对象的遍历时间，回收的也更彻底一点。

不过，这种参数有利有弊，利是降低了Remark阶段的停顿时间，弊的是在新生代对象很少的情况下也多了一次YGC，最可怜的是在AbortablePreclean阶段已经发生了一次YGC，然后在该阶段又傻傻的触发一次。

所以利弊需要把握。

主动Old GC

这个主动Old GC的过程，触发条件比较苛刻：

1. YGC过程发生Promotion Failed，进而对老年代进行回收
2. System.gc()，前提是添加了-XX:+ExplicitGCInvokesConcurrent参数

如果触发了主动Old GC，这时周期性Old GC正在执行，那么会夺过周期性Old GC的执行权（同一个时刻只能有一种在Old GC在运行），并记录 concurrent mode failure 或者 concurrent mode interrupted。

主动GC开始时，需要判断本次GC是否要对老年代的空间进行Compact（因为长时间的周期性GC会造成大量的碎片空间），判断逻辑实现如下：

1. *should_compact =
2. UseCMSCompactAtFullCollection&&
3. ((_full_gcs_since_conc_gc >=CMSFullGCsBeforeCompaction)||
4. GCCause::is_user_requested_gc(gch->gc_cause())||
5. gch->incremental_collection_will_fail(true/* consult_young */));

在三种情况下会进行压缩：

1. 其中参数 UseCMSCompactAtFullCollection(默认true)和CMSFullGCsBeforeCompaction(默认0)，所以默认每次的主动GC都会对老年代的内存空间进行压缩，就是把对象移动到内存的最左边。
2. 当然了，比如执行了 System.gc()，也会进行压缩。
3. 如果新生代的晋升担保会失败。

带压缩动作的算法，称为MSC，标记-清理-压缩，采用单线程，全暂停的方式进行垃圾收集，暂停时间很长很长...

那不带压缩动作的算法是什么样的呢？

不带压缩动作的执行逻辑叫 ForegroundCollect，整个过程相对周期性Old GC来说，少了Precleaning和AbortablePreclean两个阶段，其它过程都差不多。

CMS收集器和G1收集器的优缺点

CMS收集器和G1收集器 他们的优缺点对比 G1只有并发标记才不会stop-the-world 其他都会停下来(阿里多次问到)

CMS收集算法 参考：图解 CMS 垃圾回收机制原理，-阿里面试题

G1收集算法 参考：G1 垃圾收集器入门

首先要知道 Stop the world的含义(网易面试)：不管选择哪种GC算法，stop-the-world都是不可避免的。Stop-the-world意味着从应用中停下来并进入到GC执行过程中去。一旦Stop-the-world发生，除了GC所需的线程外，其他线程都将停止工作，中断了的线程直到GC任务结束才继续它们的任务。GC调优通常就是为了改善stop-the-world的时间 

CMS收集器是一种以获取最短回收停顿时间为目标的收集器，CMS收集器是基于“”标记--清除”(Mark-Sweep)算法实现的，整个过程分为四个步骤：  

          1. 初始标记 (Stop the World事件 CPU停顿， 很短) 初始标记仅标记一下GC Roots能直接关联到的对象，速度很快；

           2. 并发标记 (收集垃圾跟用户线程一起执行) 初始标记和重新标记任然需要“stop the world”，并发标记过程就是进行GC Roots Tracing的过程；

           3. 重新标记 (Stop the World事件 CPU停顿，比初始标记稍微长，远比并发标记短)修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记时间短

           4. 并发清理 -清除算法；

　　整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。 

初始标记：仅仅是标记一下GC roots 能直接关联的对象，速度很快  (何为GC roots :

在Java语言中，可作为GC Roots的对象包括4种情况：

  a) 虚拟机栈中引用的对象（栈帧中的本地变量表）；

  b) 方法区中类静态属性引用的对象；

  c) 方法区中常量引用的对象；

  d) 本地方法栈中JNI（Native方法）引用的对象。

具体参考：JVM的垃圾回收机制 总结(垃圾收集、回收算法、垃圾回收器)) 

CMS是一款优秀的收集器，它的主要优点是：并发收集、低停顿，但他有以下3个明显的缺点：

优点：并发收集，低停顿 

理由： 由于在整个过程和中最耗时的并发标记和 并发清除过程收集器程序都可以和用户线程一起工作，所以总体来说，Cms收集器的内存回收过程是与用户线程一起并发执行的

缺点：

   1.CMS收集器对CPU资源非常敏感 

      在并发阶段，虽然不会导致用户线程停顿，但是会因为占用了一部分线程使应用程序变慢，总吞吐量会降低，为了解决这种情况，虚拟机提供了一种“增量式并发收集器” 

的CMS收集器变种， 就是在并发标记和并发清除的时候让GC线程和用户线程交替运行，尽量减少GC 线程独占资源的时间，这样整个垃圾收集的过程会变长，但是对用户程序的影响会减少。（效果不明显，不推荐） 

  2. CMS处理器无法处理浮动垃圾 

      CMS在并发清理阶段线程还在运行， 伴随着程序的运行自然也会产生新的垃圾，这一部分垃圾产生在标记过程之后，CMS无法再当次过程中处理，所以只有等到下次gc时候在清理掉，这一部分垃圾就称作“浮动垃圾” ， 

  3. CMS是基于“标记--清除”算法实现的，所以在收集结束的时候会有大量的空间碎片产生。空间碎片太多的时候，将会给大对象的分配带来很大的麻烦，往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象的，只能提前触发 full gc。 

    为了解决这个问题，CMS提供了一个开关参数，用于在CMS顶不住要进行full gc的时候开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片没有了，但是停顿的时间变长了  

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

G1(Garbage First)是一款面向服务端应用的垃圾收集器。G1具备如下特点：

5、G1运作步骤：

1、初始标记(stop the world事件 CPU停顿只处理垃圾)；

2、并发标记(与用户线程并发执行)；

3、最终标记(stop the world事件 ,CPU停顿处理垃圾)；

4、筛选回收(stop the world事件 根据用户期望的GC停顿时间回收)(注意：CMS 在这一步不需要stop the world)（阿里问为何停顿时间可以设置，参考：G1 垃圾收集器架构和如何做到可预测的停顿(阿里)）

与其他GC收集器相比，G1具备如下特点：

1、并行于并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。

2、分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。它能够采用不同的方式去处理新创建的对象和已经存活了一段时间，熬过多次GC的旧对象以获取更好的收集效果。

3、空间整合：与CMS的“标记--清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。

4、可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1和ＣＭＳ共同的关注点，但Ｇ１除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，

 

上面几个步骤的运作过程和CMS有很多相似之处。初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS的值，让下一个阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这一阶段需要停顿线程，但是耗时很短，并发标记阶段是从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段时耗时较长，但可与用户程序并发执行。而最终标记阶段则是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remenbered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这一阶段需要停顿线程，但是可并行执行。最后在筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。