CMS 垃圾回收器与G1 垃圾回收器

Posted 2021-07-24 无恙_z

CMS 垃圾回收器

CMS(Concurrent Mark Sweep)收集器，以获取最短回收停顿时间（也就是指Stop The World的停顿时间，即轻GC的时间）为目标。其中Concurrent是指垃圾收集的线程和用户执行的线程是可以同时执行的。

CMS 垃圾回收器采用的是"标记-清除"算法，整个过程大致分为4个步骤（详细的话有七个步骤）：

1. 初始标记：即标记一下与GC Roots直接有关联的对象，速度很快。（会触发Stop The World停顿！）
2. 并行标记：即垃圾回收的线程与用户的线程可以一起执行，这个阶段会遍历老年代，然后标记所有存活的对象，它会根据上个阶段找到GC ROOTS遍历查找。
3. 重新标记：因为在并行标记时，可能用户线程会对已经标记过的对象进行改动，重新标记就是为了修正这个对象的标记。（会触发Stop The World停顿！停顿时间比初始标记阶段稍长，但远比并行标记的时间短！）
4. 并行清理：即垃圾回收的线程去回收垃圾。

空间分配担保

在轻GC之前，会先去判断老年代的最大连续可用空间是否大于新生代所有的对象的空间总和。如果大于的话，那么此次轻GC是安全的。当大量对象在轻GC后仍然存活，就需要老年代进行空间分配担保，把Survivor无法容纳的对象直接进入老年代。如果老年代判断到剩余空间不足（根据以往每一次回收晋升到老年代对象空间的平均值作为经验值），则进行一次Full GC。

优缺点

优点：并发收集、低停顿（停顿指的是停止用户线程）。
缺点：

• CMS收集器对CPU资源非常敏感。
• CMS收集器无法处理浮动垃圾。
• 由于使用的是标记-清除算法，会产生大量的空间碎片，将会给大对象分配带来很大麻烦。

G1 垃圾回收器

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

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

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

G1内存的物理内存的布局方式是彻底颠覆了，整个堆空间不做任何明确的大块的划分，每个区域到底是伊甸园区，还是幸存区，还是老年代，并没有统一的规则。

G1 收集器的运作大致分为以下几个步骤：

1. 初始标记
2. 并发标记
3. 最终标记
4. 筛选回收

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