垃圾回收-垃圾回收器(一)

玉衡子
117 阅读14分钟

垃圾回收-垃圾回收器(一)

垃圾收集器.png

上图连线部分标识可以相互配合使用的垃圾收集器

Oracle官方认可的jvm垃圾收集器如下： 针对新生代：Serial、Parallel Scavenge、Parallel New 针对老年代：Seiral Old、Parallel Old、CMS 横跨新生代和老年代：G1、ZGC

这篇文章我将向你们介绍JDK8中常用的垃圾收集器，G1和ZGC我将放到下一章节再向你介绍。

Serial收集器(-XX:+UseSerialGC -XX:+UseSerialOldGC)

Serial（串行）收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收集器了。它的“单线程”的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（"Stop The World"），直到它收集结束。

serial执行流程.jpeg

看到串行相信你自然而然会想到，这种算法会导致stw时间较长，对于用户体验来说就不好了。所以在后续的垃圾收集器设计中停顿时间在不断缩短。

Serial收集器的优点：简单而高效（与其他收集器的单线程相比）。Serial收集器由于没有线程交互的开销，自然可以获得很高的单线程收集效率。

Serial Old收集器是Serial收集器的老年代版本，它同样是一个单线程收集器。它主要有两大用途：一种用途是在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备方案兜底的。

Serial垃圾收集器：新生代采用复制算法，老年代采用标记-整理算法。 在《垃圾回收-算法详解》中我有向你提到过复制算法效率很高的，标记整理就比较慢了。所以这也是我们要尽量避免full gc的一个原因。

Parallel Scavenge收集器(-XX:+UseParallelGC(年轻代),-XX:+UseParallelOldGC(老年代))

Parallel收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和Serial收集器类似。默认的收集线程数跟cpu核数相同，当然也可以用参数(-XX:ParallelGCThreads)指定收集线程数，但是一般不推荐修改。

Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值，越大标识吞吐量越高。 Parallel Scavenge收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解的话，可以选择把内存管理优化交给虚拟机去完成也是一个不错的选择。

同样Parallel Scavenge 新生代采用复制算法，老年代采用标记-整理算法。

parallel执行流程.jpeg

Parallel Old收集器是Parallel Scavenge收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及CPU资源的场合，都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器(JDK8默认的新生代和老年代收集器)。

ParNew收集器(-XX:+UseParNewGC)

ParNew收集器其实跟Parallel收集器很类似，区别主要在于它可以和CMS收集器配合使用。

ParNew收集器专门用于新生代：新生代采用复制算法

ParNew执行流程.jpeg

它是许多运行在Server模式下的虚拟机的首要选择，除了Serial收集器外，只有它能与CMS收集器（真正意义上的并发收集器，后面会介绍到）配合工作。

CMS收集器(-XX:+UseConcMarkSweepGC(old))

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

从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

  • 初始标记： 暂停所有的其他线程(STW)，并记录下gc roots直接能引用的对象，速度很快。
  • 并发标记： 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。
  • 重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录(主要是处理漏标问题)，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三色标记里的增量更新算法(见下面详解)做重新标记。
  • 并发清理： 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理(见下面三色标记算法详解)。
  • 并发重置： 重置本次GC过程中的标记数据。

CMS执行流程.jpeg

CMS主要优点：并发收集、低停顿。

但是它有下面几个明显的缺点：

  • 对于cpu资源敏感（会争抢服务器资源）
  • 无法处理并发标记和清理导致的浮动垃圾，需要等到下一次gc才行
  • 使用的标记-清除算法，会导致大量磁盘碎片，当然通过参数-XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理
  • 执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent mode failure"，此时会进入stop the world，用serial old垃圾收集器来回收。

CMS的相关核心参数

  1. -XX:+UseConcMarkSweepGC：启用cms 
  2. -XX:ConcGCThreads：并发的GC线程数
  3. -XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）
  4. -XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次
  5. -XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）
  6. -XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整
  7. -XX:+CMSScavengeBeforeRemark：用于在CMS垃圾收集器的重新标记阶段（Remark）之前，强制触发一次年轻代的垃圾回收。其目的是减少需要扫描的对象数量，从而缩短重新标记阶段的停顿时间。
  8. -XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW
  9. -XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;

三色标记

在并发标记的过程中，因为标记期间应用线程还在继续跑，对象间的引用可能发生变化，多标和漏标的情况就有可能发生。漏标的问题主要引入了三色标记算法来解决。

三色标记算法是把GC Root可达性分析时遍历的对象，按照条件“是否访问过”在对象头上打上不同的标记。

  • 黑色： 表示对象已经被垃圾收集器访问过， 且这个对象的所有引用都已经扫描过。 黑色的对象代表已经扫描过， 它是安全存活的， 如果有其他对象引用指向了黑色对象， 无须重新扫描一遍。 黑色对象不可能直接（不经过灰色对象） 指向某个白色对象。
  • 灰色： 表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。
  • 白色： 表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段，所有的对象都是白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。

多标

在并发标记过程中，存在各种多标情况。例如：方法运行结束后导致部分局部变量(gcroot)被销毁，但是这个gcroot引用对象之前被扫描标记为非垃圾对象的话，本次gc就不会回收了。这部分应该回收但最终却没有被回收的内存，称为“浮动垃圾”。其实这种情况并不会影响垃圾回收准确性，大不了下次gc再回收。

另外，针对并发标记(还有并发清理)开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能也会变为垃圾，这也算是浮动垃圾的一部分。

漏标

漏标会导致被引用的对象被当成垃圾误删除，这是严重bug。jvm两种解决方案： 增量更新（Incremental Update）和原始快照（Snapshot At The Beginning，SATB）。

漏标问题的本质

在并发标记过程中，如果一个白色对象（未标记）被黑色对象（已标记完成）引用，同时灰色对象（正在标记）删除了对这个白色对象的引用，那么这个白色对象就会被误认为是垃圾而被回收。可以看下面这个例子

漏标问题.png

/**
 * 垃圾收集算法细节之三色标记
 * 例子
 */
public class ThreeColorRemark {

    public static void main(String[] args) {
        A a = new A();

        //开始做并发标记（下面代码并发标记和用户线程同时执行）
        D d = a.b.d;   // 1.读
        a.b.d = null;  // 2.写
        a.d = d;       // 3.写
        d = null;      // 4.写
    }
}

class A {
    B b = new B();
    D d = null;
}

class B {
    C c = new C();
    D d = new D();
}

class C {
}

class D {
}
增量更新

核心思想：监控黑色对象的"新增引用"行为

工作原理：

  • 当黑色对象新增一个指向白色对象的引用时，记录这个操作
  • 并发标记结束后，以这些黑色对象为根重新扫描
  • 相当于让黑色对象"退回"成灰色对象，确保不会遗漏

举例：假设对象A（黑色）新增了对对象C（白色）的引用，增量更新会记录"A→C"这个引用关系，后续重新扫描A，确保C被正确标记。

原始快照

核心思想：监控灰色对象的"删除引用"行为

工作原理：

  • 当灰色对象要删除指向白色对象的引用时，记录这个即将被删除的引用
  • 并发标记结束后，以记录的灰色对象为根重新扫描
  • 确保原本可达的白色对象不会被误删 举例：假设对象B（灰色）要删除对对象C（白色）的引用，SATB会记录"B→C"这个引用关系，即使B删除了对C的引用，后续仍会重新扫描B，将C标记为存活。(目的就是防止漏标，让这种对象在本轮gc清理中能存活下来，待下一轮gc的时候重新扫描，这个对象也有可能是浮动垃圾)
关键区别
  • 增量更新：关注"谁新增了引用"（黑色对象的行为）
  • 原始快照：关注"谁删除了引用"（灰色对象的行为） 两种方案都能有效解决漏标问题，但实现机制不同。CMS使用增量更新，G1使用原始快照。

以上无论是对引用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的。

写屏障

给某个对象的成员变量赋值时，其底层代码大概长这样：

/**
* @param field 某对象的成员变量，如 a.b.d 
* @param new_value 新值，如 null
*/
void oop_field_store(oop* field, oop new_value) { 
    *field = new_value; // 赋值操作
}

所谓的写屏障，其实就是指在赋值操作前后，加入一些处理（可以参考AOP的概念）：

void oop_field_store(oop* field, oop new_value) {  
    pre_write_barrier(field);          // 写屏障-写前操作
    *field = new_value; 
    post_write_barrier(field, value);  // 写屏障-写后操作
}

写屏障实现SATB

当对象B的成员变量的引用发生变化时，比如引用消失（a.b.d = null），我们可以利用写屏障，将B原来成员变量的引用对象D记录下来：

void pre_write_barrier(oop* field) {
    oop old_value = *field;    // 获取旧值
    remark_set.add(old_value); // 记录原来的引用对象
}

写屏障实现增量更新

当对象A的成员变量的引用发生变化时，比如新增引用（a.d = d），我们可以利用写屏障，将A新的成员变量引用对象D记录下来：

void post_write_barrier(oop* field, oop new_value) {  
    remark_set.add(new_value);  // 记录新引用的对象
}

读屏障

oop oop_field_load(oop* field) {
    pre_load_barrier(field); // 读屏障-读取前操作
    return *field;
}

读屏障是直接针对第一步：D d = a.b.d，当读取成员变量时，一律记录下来：

void pre_load_barrier(oop* field) {  
    oop old_value = *field;
    remark_set.add(old_value); // 记录读取到的对象
}

现代追踪式（可达性分析）的垃圾回收器几乎都借鉴了三色标记的算法思想，尽管实现的方式不尽相同：比如白色/黑色集合一般都不会出现（但是有其他体现颜色的地方）、灰色集合可以通过栈/队列/缓存日志等方式进行实现、遍历方式可以是广度/深度遍历等等。

对于读写屏障，以Java HotSpot VM为例，其并发标记时对漏标的处理方案如下：

  • CMS：写屏障 + 增量更新
  • G1，Shenandoah：写屏障 + SATB
  • ZGC：读屏障

工程实现中，读写屏障还有其他功能，比如写屏障可以用于记录跨代/区引用的变化，读屏障可以用于支持移动对象的并发执行等。功能之外，还有性能的考虑，所以对于选择哪种，每款垃圾回收器都有自己的想法。

为什么G1用SATB？CMS用增量更新？

SATB相对增量更新效率会高(当然SATB可能造成更多的浮动垃圾)，因为不需要在重新标记阶段再次深度扫描被删除引用对象，而CMS对增量引用的根对象会做深度扫描，G1因为很多对象都位于不同的region，CMS就一块老年代区域，重新深度扫描对象的话G1的代价会比CMS高，所以G1选择SATB不深度扫描对象，只是简单标记，等到下一轮GC再深度扫描。

总结

本文介绍了JDK8中的主要垃圾回收器：

串行收集器

  • Serial/Serial Old：单线程，适用于小型应用，STW时间较长
  • 新生代用复制算法，老年代用标记-整理算法

并行收集器

  • Parallel Scavenge/Parallel Old：多线程版Serial，关注吞吐量，JDK8默认
  • ParNew：专门配合CMS使用的新生代收集器

并发收集器

  • CMS：首款真正并发收集器，关注停顿时间，使用标记-清除算法
  • 四个阶段：初始标记→并发标记→重新标记→并发清理
  • 缺点：CPU敏感、浮动垃圾、内存碎片、并发失败风险

核心技术

  • 三色标记算法：解决并发标记中的漏标问题
    • 白色（未访问）、灰色（部分扫描）、黑色（完全扫描）
  • 漏标解决方案：
    • 增量更新：记录黑色对象新增的引用（CMS采用）
    • 原始快照(SATB)：记录灰色对象删除的引用（G1采用）
  • 写屏障：在赋值操作前后插入处理逻辑，实现引用变化的监控

各收集器在吞吐量与停顿时间之间做出不同权衡，为不同应用场景提供最优解决方案。

avatar
文章
阅读
粉丝