G1(Garbage First)垃圾收集器是目前垃圾回收技术最前沿的成果之一。
G1 同 CMS 垃圾回收器一样,关注最小时延的垃圾回收器,适合大尺寸堆内存的垃圾收集。但是,G1 最大的特点是引入分区的思路,弱化了分代的概念,合理利用垃圾收集各个周期的资源,解决了其他收集及 CMS 的很多缺陷。
官方推荐使用 G1 来代替 CMS。
通过本篇,我们可以了解掌握 G1 收集器的基本概念、堆内存、回收流程、GC模式、推荐用例等核心知识。
目录
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 内存模型
- 新生代:伊甸园区 (eden space) + 2个幸存区
- 老年代
- 持久代 (perm space):JDK1.8 之前
- 元空间 (metaspace):JDK1.8 之后取代持久代
2. G1收集器的内存模型
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 收集器的阶段,大致分为以下步骤:
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 GC、Mixed 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 的互联网架构」系列文章作者,专注于互联网架构技术。
标签:G1,收集器,内存,GC,垃圾,CMS,图文 From: https://www.cnblogs.com/mikechenshare/p/16851342.html