查看原文
其他

深入理解G1垃圾收集器

zhaoyh SpringForAll社区 2021-05-27

点击上方☝SpringForAll社区 轻松关注!

及时获取有趣有料的技术文章
本文来源:http://r6d.cn/bbv61

1. 垃圾收集器简析

Java语言一直使用GC技术进行JVM自动内存管理,避免手动管理带来的一系列问题,以提升开发人员效率。衡量垃圾回收的三个最重要指标:

  • 内存占用(Footprint);
  • 吞吐量(Throughput);
  • 延迟(Latency);

目前的垃圾收集器能是尽量在这三个指标中寻找平衡,以达到最大的回收效率,能同时达到这三个指标完美的垃圾收集器是比较困难的,但是随着20多年来垃圾收集器的技术进步,一款优秀的收集器也越来越满足大家的需求。目前,比较经典的垃圾收集器有如下几种:

  • Serial收集器,历史最悠久,GC是单线程,会有“Stop The World”,内存消耗最小,作用于新生代,基于标记-复制算法实现;
  • Serial Old收集器,是Serial的老年代版本,基于标记-整理算法实现,在JDK5及之前,和Parallel Scavenge搭配使用,以及作为CMS失败时的备选方案;
  • ParNew收集器,是Serial收集器的多线程并行版本,作用于新生代,基于标记-复制算法实现,也会暂停所有用户线程;
  • Parallel Scavenge收集器,作用于新生代,基于标记-复制算法实现,侧重于吞吐量,有自适应调节策略,合理搭配新生代和老年代大小;
  • Parallel Old收集器,是Parallel Scavenge的老年代版本,基于标记-整理算法实现,JDK6开始提供;
  • CMS收集器,作用于老年代,目标是低延迟,收集速度较快,基于标记-清除算法实现,会有内存碎片;

各垃圾收集器作用域及组合关系可参考下图:

2. G1收集器

2.1 G1收集器介绍

Garbage First(G1)收集器是垃圾回收技术发展历史上里程碑式的成果,它开创了收集器面向局部收集的设计思路和基于Region的堆内存布局,自JDK7之后开始发布,到了JDK8 Update 40版本后,G1提供了类卸载的支持,这个版本的G1被Oracle称为全功能垃圾收集器(Fully-Featured Garbage Collector)。G1主要面向服务端应用,自JDK9之后,G1取代了Parallel Old + Parallel Old的组合,成为服务端模式下的默认垃圾收集器。也是自JDK9之后,CMS和Serial Old被标记为废弃(Deprecate)状态而不再推荐使用。

经典的GC收集器将对内存按代划分,这种划代方式的内存在逻辑上是连续的。而G1垃圾收集器将堆内存按Region划分,回收的衡量标准不再是它属于哪个分代,而是哪块内存中存放的垃圾数量最多,回收收益最大,这就是G1收集器独有的Mixed GC模式。

2.2 G1收集器堆内存分布

G1收集器的堆内存布局可参考下图:

  • E,新生代Eden空间;
  • S,新生代Survivor空间;
  • O,老年代空间;
  • H,Humongous区域,专门用来存储大对象;

G1其实也遵循了按代回收的理念,只是不再固定的分配各代的大小,而是把连续的堆划分为多个大小相等的独立空间(Region),每一个Region,可以根据需要,扮演新生代(Eden、Survivor)、老年代的角色。收集器能够对扮演不同角色的Region采用不同的策略去处理,这样无论是新对象还是老对象,熬过多次收集的旧对象都能够有较好的收集效果。G1中还有一类Humongous区域,G1认为大小大于等于Region一半的对象即可判定为大对象。对于超过1个Region容量的大对象,将会被存放在N个连续的H Region之中,G1的大多数行为都把H Region作为来年代的一部分来看待。

每个Region的大小可通过参数-XX:G1HeapRegionSize设定,取值范围1~32MB,且应该为2的N次幂。

2.3 停顿预测模型

停顿预测模型(Pause Prediction Model)是指能够支持指定在一个长度为M的时间片段内,垃圾回收的时间不超过N的模型。G1的内存被划分为一系列不需要连续区域,即将Region作为单次回收的最小单元,每次垃圾回收到的空间都是Region大小的整数倍,这样可以有计划地避免在整个堆空间收集,也更容易控制垃圾回收时间。G1也会跟踪各个Region的价值大小,建立各个Region空间的优先级列表,已达到最大化的垃圾收集的收益。

那么如何建立可靠的停顿预测模型呢?用户在启动Java程序时可以通过-XX:MaxGCPauseMillis指定停顿时间的最大期望值,在垃圾收集过程中,G1收集每个Region的回收耗时,再根据历史数据的偏差、置信度等统计数据,由哪些Region组成的回收集合才能达到期望停顿值之内的最高收益。

//  share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
double get_new_prediction(TruncatedSeq* seq) {
    return MAX2(seq->davg() + sigma() * seq->dsd(),
                seq->davg() * confidence_factor(seq->num()));
}

在这个预测计算公式中:davg表示衰减均值,sigma()返回一个系数,表示信赖度,dsd表示衰减标准偏差,confidence_factor表示可信度相关系数。而方法的参数TruncateSeq,是一个截断的序列,它只跟踪了序列中的最新的n个元素。TruncateSeq(继承了AbsSeq)中,用来计算衰减均值、衰减变量,衰减标准偏差等:

// src/share/vm/utilities/numberSeq.cpp
void AbsSeq::add(double val) {
  if (_num == 0) {
    // if the sequence is empty, the davg is the same as the value
    _davg = val;
    // and the variance is 0
    _dvariance = 0.0;
  } else {
    // otherwise, calculate both
    _davg = (1.0 - _alpha) * val + _alpha * _davg;
    double diff = val - _davg;
    _dvariance = (1.0 - _alpha) * diff * diff + _alpha * _dvariance;
  }
}

3. G1收集器运行过程

3.1 需要思考的问题

将Java堆按Region划分后,跨Region对象的引用怎么解决?G1的解决办法是每个Region维护自己的记忆集(Remembered Set),可以看做一个哈希表,key是别的Region的地址,value是本地的索引,通过这种双向的结构,记录下“我指向谁”和“谁指向我”的问题。由于需要额外记录这些数据,G1比其他经典收集器多了很多内存占用。

在并发标记阶段如何保证收集线程和用户线程互不干扰的运行?如果GC线程标记对象时,用户线程改变了对象之间的引用关系,必须保证不能打破原有的对象依赖图结构,G1采用原始快照(SATB,Snapshot At The Begining)算法来实现,由字面理解,SATB是GC开始时活着的对象的一个快照。根据对象标记算法,把遍历对象图结构中遇到的对象,按照“是否被访问过”分为三种颜色:

  • 白色,该对象未被垃圾收集器访问过,在可达性分析阶段结束后,若仍是白色,即代表对象不可达,会被当做垃圾收集掉;
  • 黑色,对象已经被垃圾收集器访问过,且对象的所有引用也被扫描过了,它是安全存活的,因此黑色对象不可能指向白色对象;
  • 灰色,表示对象已被垃圾收集器访问过,但这个对象还至少有一个引用还没有扫描过;

此时,若用户线程和GC线程并发工作,用户也要修改对象间的引用关系结构,这样就会产生两种后果:一种是把原本消亡的对象标记为存活;另一种是会把原本存活的对象标记为消亡。

SATB快照的存在,就可以让G1采用如下办法解决上述问题:当灰色对象要删除指向白色对象的引用关系时,就将这个要删除的引用记录下来,在并发扫描结束后,再以记录过的引用关系中的灰色对象为根,重新扫描一次,这样无论引用关系删除与否,都会按照最初的对象结构图进行搜索。虚拟机通过写屏障,实现操作记录的记录和修改,避免并发带来的问题。

G1垃圾收集器在收集过程中,此时若用户线程还在创建新对象,G1在每个Region中划出一部分空间用于垃圾收集过程中的新对象分配,而且在收集过程中,默认这块区域的对象都是存活的。

如果内存回收的速度赶不上内存分配的速度,G1收集器也要被迫冻结用户线程的执行,导致Full GC而产生较长时间的”Stop The World”。

3.2 垃圾回收过程

  • 初始标记(Initial Marking),仅标记GC Roots能直接关联到的对象,这个阶段需要停顿线程,但耗时很短,借用进行Young GC的时候同步完成的,G1收集器在这个阶段没有额外的停顿;
  • 并发标记(Concurrent Marking),从GC Root开始做可达性分析,扫描整个对象引用结构图,耗时较长,但是可与用户线程并发执行,扫描完成后,还要重新处理SATB记录下的并发时有引用修改的对象;
  • 最终标记(Final Marking),此时用户线程也需要短暂暂停,用于处理并发标记结束后仍遗留的SATB记录;
  • 筛选回收(Counting and Evacuation),更新Region数据,对Region的回收价值做优先级排序,根据用户期望时间值制定回收集合,然后把被回收的Region的存活对象复制到另一个空的Region区域,此阶段暂停所有用户线程;

从上收集过程可以看出,用户指定期望停顿时间是G1收集器很重要的参数,它会让G1收集器在吞吐量和延迟两个指标之间取一个平衡。因此设置合理的期望停顿时间是必要的,通常设置为100到200ms是比较合理的。

4. 应用及总结

4.1 G1使用

如果你的JDK是9及之后的版本,那会默认开启G1收集器,G1收集器其他相关的参数:

参数含义
-XX:+UseG1GC使用G1收集器
-XX:MaxGCPauseMillis设置G1期望停顿时间,默认值200ms
-XX:G1HeapRegionSize设置Region大小
-XX:ParallelGCThreadsSTW时间并行的线程数
-XX:ConcGCThreads并发标记阶段的线程数
-XX:G1NewSizePercent新生代占比最小值,默认值5%
-XX:G1MaxNewSizePercent新生代占比最大值,默认值60%

4.2 G1总结

G1垃圾收集器,从整体上来说,以Region划分,可以看做是基于标记-整理实现,但从局部来说,两个Region之间又是采用标记-复制的算法,因此G1垃圾收集器不会产生内存碎片,收集完成后能提供较完整的可用内存。

G1收集器的内存停顿模型,把内存的期望停顿时间交给了程序员,对控制GC停顿时间可依据不同的业务模型、硬件 条件来合理的设置。

G1收集器的额外负载高,G1的记忆集可能会占到整个堆容量的20%甚至更多。另外G1对写屏障的复杂操作要比其他收集器消耗更多的运算资源。

5. 参考文档

  • Getting Started with the G1 Garbage Collector
  • Garbage First Garbage Collector
  • Java Hotspot G1 GC的一些关键技术
  • Java中9种常见的CMS GC问题分析与解决
  • Best practice for JVM Tuning with G1 GC
  • Garbage Collectors – Serial vs. Parallel vs. CMS vs. G1

以上内容就是关于深入理解G1垃圾收集器的全部内容了,谢谢你阅读到了这里!


2021Java深入资料领取方式回复“20210112”

墙裂推荐

【深度】互联网技术人的社群,点击了解!



 海量数据优化查询的套路有哪些?

 适配器模式在Mybatis中的妙用,真秒!

 Redis官方的高可用性解决方案

 压缩20M文件从30秒到1秒的优化过程


关注公众号,回复“spring”有惊喜!!!

如果资源对你有帮助的话


❤️给个在看,是最大的支持❤️

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存