登录/注册
小开开
2649
占位
2
占位
0
浏览量
占位
粉丝
占位
关注
G1 垃圾收集器深入剖析(图文超详解)
小开开
2022-11-23 11:41:34 2022-11-23
20
0

G1垃圾收集器深入剖析(图文超详解)-mikechen的互联网架构

G1(Garbage First)垃圾收集器是目前垃圾回收技术最前沿的成果之一。

G1 同 CMS 垃圾回收器一样,关注最小时延的垃圾回收器,适合大尺寸堆内存的垃圾收集。但是,G1 最大的特点是引入分区的思路,弱化了分代的概念,合理利用垃圾收集各个周期的资源,解决了其他收集及 CMS 的很多缺陷。

官方推荐使用 G1 来代替 CMS。

通过本篇,我们可以了解掌握 G1 收集器的基本概念、堆内存、回收流程、GC模式、推荐用例等核心知识

G1垃圾收集器深入剖析(图文超详解)-mikechen的互联网架构

目录

G1 收集器概述

HotSpot 团队一直努力朝着高效收集、减少停顿 (STW: Stop The World) 的方向努力,贡献了从串行 Serial 收集器、到并行收集器 Parallerl 收集器,再到 CMS 并发收集器,乃至如今的 G1 在内的一系列优秀的垃圾收集器。

G1(Garbage First) 垃圾收集器,是关注最小时延的垃圾回收器,也同样适合大尺寸堆内存的垃圾收集,官方推荐选择使用 G1 来替代 CMS 。

1.  G1 收集器的最大特点

  • G1最大的特点是引入分区的思路,弱化了分代的概念。
  • 合理利用垃圾收集各个周期的资源,解决了其他收集器、甚至 CMS 的众多缺陷。

2.  G1 的改进(相比较 CMS ) 

  • 算法: G1 基于标记--整理算法, 不会产生空间碎片,在分配大对象时,不会因无法得到连续的空间,而提前触发一次 FULL GC 。
  • 停顿时间可控: G1可以通过设置预期停顿时间(Pause Time)来控制垃圾收集时间避免应用雪崩现象。
  • 并行与并发:G1 能更充分的利用 CPU 多核环境下的硬件优势,来缩短 stop the world 的停顿时间。

3. CMS 和 G1 的区别

  • CMS 中,被分为 PermGen,YoungGen,OldGen ;而 YoungGen 又分了两个 survivo 区域。在 G1 中,堆被平均分成几个区域 (region) ,在每个区域中,虽然也保留了新老代的概念,但是收集器是以整个区域为单位收集的。
  • G1在回收内存后,会立即同时做合并空闲内存的工作;而CMS ,则默认是在 STW(stop the world)的时候做。
  • G1会在 Young GC 中使用;而 CMS 只能在 O 区使用。

4.  G1 收集器的应用场景

目前,CMS 还是默认首选的 GC 策略。

G1 垃圾收集算法,主要应用在多 CPU 大内存的服务中,在满足高吞吐量的同时,尽可能的满足垃圾回收时的暂停时间。

在以下场景中,G1 更适合:

  • 服务端多核 CPU、JVM 内存占用较大的应用(至少大于4G);
  • 应用在运行过程中,会产生大量内存碎片、需要经常压缩空间;
  • 想要更可控、可预期的 GC 停顿周期,防止高并发下应用雪崩现象。

G1 的堆内存算法

1.  G1 之前的 JVM 内存模型

G1垃圾收集器深入剖析(图文超详解)-mikechen的互联网架构

  • 新生代:伊甸园区 (eden space) + 2个幸存区
  • 老年代
  • 持久代 (perm space):JDK1.8 之前
  • 元空间 (metaspace):JDK1.8 之后取代持久代

2. G1收集器的内存模型

G1垃圾收集器深入剖析(图文超详解)-mikechen的互联网架构

2.1  G1 堆内存结构

堆内存会被切分成为很多个固定大小区域(Region),每个是连续范围的虚拟内存。

堆内存中一个区域 (Region) 的大小,可以通过 -XX:G1HeapRegionSize 参数指定,大小区间最小 1M 、最大 32M ,总之是 2 的幂次方。

默认是将堆内存按照2048 份均分。

2.2  G1 堆内存分配

每个 Region 被标记了 E、S、O 和 H,这些区域在逻辑上被映射为 Eden,Survivor 和老年代。

存活的对象从一个区域转移(即复制或移动)到另一个区域。区域被设计为并行收集垃圾,可能会暂停所有应用线程。如上图所示,区域可以分配到 Eden,survivor 和老年代。

此外,还有第四种类型,被称为巨型区域(Humongous Region)。

Humongous 区域主要是为存储超过 50% 标准 region 大小的对象设计,它用来专门存放巨型对象。如果一个 H 区装不下一个巨型对象,那么 G1 会寻找连续的 H 分区来存储。为了能找到连续的 H 区,有时候不得不启动 Full GC 。

G1 回收流程

在执行垃圾收集时,G1 以类似于 CMS 收集器的方式运行。

1. G1 收集器的阶段,大致分为以下步骤:

G1垃圾收集器深入剖析(图文超详解)-mikechen的互联网架构

1.1  G1 执行的第一阶段:初始标记 ( Initial Marking )

这个阶段是 STW(Stop the World ) 的,所有应用线程会被暂停,标记出从 GC Root 开始直接可达的对象。

1.2  G1 执行的第二阶段:并发标记

从 GC Roots 开始,对堆中对象进行可达性分析,找出存活对象,耗时较长。

当并发标记完成后,开始最终标记 ( Final Marking ) 阶段。

1.3  最终标记

标记那些在并发标记阶段发生变化的对象,将被回收。

1.4  筛选回收

首先,对各个 Regin 的回收价值和成本进行排序,根据用户所期待的 GC 停顿时间,来指定回收计划,回收一部分 Region 。

G1中提供了Young GCMixed GC两种垃圾回收模式,这两种垃圾回收模式,都是 Stop The World(STW) 的。

G1 的 GC 模式

1. YoungGC 年轻代收集

在分配一般对象(非巨型对象)时,当所有 eden region 使用达到最大阀值、并且无法申请足够内存时,会触发一次 YoungGC 。

每次 younggc 会回收所有Eden 、以及 Survivor 区,并且将存活对象复制到 Old 区以及另一部分的 Survivor 区。

YoungGC 的回收过程

  • 根扫描,跟 CMS 类似,Stop the world,扫描 GC Roots 对象;
  • 处理 Dirty card,更新 RSet;
  • 扫描 RSet ,扫描 RSet 中所有 old 区,对扫描到的 young 区或者 survivor 区的引用;
  • 拷贝扫描出的存活的对象到 survivor2/old 区;
  • 处理引用队列、软引用、弱引用、虚引用。

2. mixed gc

当越来越多的对象晋升到老年代 old region 时,为了避免堆内存被耗尽,虚拟机会触发一个混合的垃圾收集器,即 mixed gc ,该算法并不是一个 old gc ,除了回收整个 young region ,还会回收一部分的 old region 。

这里需要注意:是一部分老年代,而不是全部老年代,可以选择哪些 old region 进行收集,从而可以对垃圾回收的耗时时间进行控制。

G1 没有 fullGC 概念,需要 fullGC 时,调用 serialOldGC 进行全堆扫描(包括 eden、survivor、o、perm)。

G1 的推荐用例

G1 的第一个重要特点:是为用户的应用程序的提供一个低GC延时和大内存GC的解决方案。

这意味着堆大小 6GB 或更大,稳定和可预测的暂停时间将低于 0.5 秒。

如果应用程序使用 CMS 或 ParallelOld 垃圾回收器,具有一个或多个以下特征,将有利于切换到 G1:

  • Full GC 持续时间太长或太频繁;
  • 对象分配率或年轻代升级老年代很频繁;
  • 不期望的很长的垃圾收集时间或压缩暂停(超过 0.5 至 1 秒)。

注意:

如果你正在使用 CMS 或 ParallelOld 收集器,且应用程序没有遇到长时间的垃圾收集暂停,则保持当前收集器就可以了。升级 JDK ,并不需要更新收集器为 G1 。

以上,是 G1 垃圾收集器的解析,欢迎评论区留言交流或拓展。

如果觉得有用,请顺手关注+推荐+转发支持下,谢谢。

作者简介

陈睿 | mikechen , 10年+大厂架构经验,「mikechen 的互联网架构」系列文章作者,专注于互联网架构技术。

👇阅读「mikechen 的互联网架构」40W 字技术文章合集👇

Java 并发 | JVM | MySQL | Spring | Redis | 分布式 | 高并发

--- end ---

暂无评论