# G1 GC核心原理介绍

今天让我们从0开始了解G1 GC。

在开始之前,我们先探讨下为什么我们学习G1 GC。 要学习一些新知识,每个人可能都有不同的目的目标。 我认为学习G1GC对于Java工程师有如下收益。

  1. 成为更好的Java开发工程师,在遇到服务性能问题、GC问题时,能够通过了解到的G1知识快速定位、解决相关问题
  2. 在面试时GC问题也是常问的知识点,G1GC作为大多数工程师了解不是很多的知识领域,如果稍微深入理解,就能形成更大的领先优势,无论是被面试还是面试别人
  3. 学习G1中的优化技巧、原理,有机会能够举一反三应用到平时的工作设计中
  4. 满足自己的好奇心,了解一项事物背后的运行流程。

目前大多数人对于G1 GC的知识理解可能来自G1 GC论文、oracle官方文档、《深入理解Java虚拟机》书籍、网络文章等。 而其中一些内容可能已经过时或描述不全面,本文会尽量给大家带来更准确、全面的G1理解。

# G1核心设计思路介绍

G1GC是Garbage First Garbage Collection的简写,G1读作G one或G 一都是可以的。 在jdk9之后的版本,G1已经成为默认的垃圾回收器。

在G1出现之前,服务端Java服务普遍使用CMS(并发标记清除回收器),在暂定时间、吞吐量等方面G1相比CMS有全面的优化, 所以jdk9之后CMS也已经从jdk代码中移除不能再使用。

那么CMS遇到了哪些问题呢?

这要从GC暂停时间开始说起,在JVM运行时,除了有mutator应用线程(我们写的业务代码)执行,还有JVM内部的一些代码在运行就包括了GC的线程。 mutator是GC领域对于应用代码的称呼,mutator对堆内存中的对象进行创建、修改、使用。 目前绝大部分的Java GC在回收内存时,都或多或少地需要暂停mutator,后面我们会讲解暂停的原因。

在GC过程中暂停mutator,暂停结束后,mutator继续运行。暂停可能导致请求耗时增加,如果较长会导致请求超时、用户体验变差、mutator访问外部资源超时 等问题。

以CMS为例,CMS是用于回收老年代的收集器,对于年轻代需要使用ParNew回收,这样的组合存在以下问题。

  1. 年轻代和老年代的大小固定,而年轻代回收时的暂停时间和回收的内存区域相关,随着业务量级变大、业务代码复杂(比如更多本地缓存),需要的堆内存会变大所以暂停时间也会相应增加。
  2. 对于老年代,CMS使用并发标记清除的方式,并发标记清除中虽然使用了很多并发处理技术降低mutator暂停时间,但是会带来内存碎片问题随着内存碎片增多,如果老年代内存持续增长可能会导致长时间暂停的Full GC
  3. 为了解决内存碎片问题,CMS还提供了一个运行N次普通CMS后运行一次带Compaction压缩的CMS,而压缩涉及到存活对象的移动,对于老年代存活对象较多的情况,也会导致较长的暂停时间

所以CMS是不能保证/控制对于mutator的暂停时间的,而一些情况下我们希望控制系统的暂停时间,比如接口的响应时间有要求最大200ms,如果我们的GC暂停时间 就超过200ms,则这样的响应时间是无法得到保证的。

为了解决这样的问题,G1 GC来了,G1 GC和CMS的核心区别也是G1的核心设计思想在于,动态控制每次回收的内存范围,通过控制内存回收区域,G1能够控制最大暂停时间, 并且G1回收时优先选择回收效率较高的内存区域提供吞吐量。

g1-region

G1将堆内存划分为若干个(接近2048个)相同大小的Region(区域),Region的大小会通过堆内存除以2048并向上查找最近的1MB, 2MB, 4MB, 8MB, 16MB, 32MB。 Region使用这样的大小目的是便于位运算,比如region大小为2MB,计算一个对象所在的region index只需要对对象地址(bit单位)左移24位(2的24次方个bit是2MB)。 G1 GC同样适用分代收集策略,每个Region可以属于年轻代(细分为Eden和Survivor)和老年代(Old),没有对象的region类型是Free,存放大于region一半大小的region是Humongous巨型region。 每次回收时,G1会选择一部分region进行回收,经历多次年轻代回收的年轻代对象达到年轻阈值后会晋升到老年代region。 region的属性会随着GC运行而变化,比如一个region开始属于eden类型,region gc回收后变成Free,然后再后面可能变成Eden、Survivor、Old、Humongous中的任意一种。 这也意味着G1中的年轻代、老年代region不是连续的,并且G1能够动态调整年轻代的大小以便控制暂停时间。

region类型总结

  • Eden - Eden region用于分配mutator的创建对象的内存,分配过程默认使用TLAB(Thread Local Allocation Buffer)提高多线程并发分配能力
  • Survivor - 回收年轻代region时,存活对象会移动到Survivor区域,Survivor放不下的或者对象gc年龄超过晋升阈值的会移动到老年代region
  • Old - 老年代region
  • Humongous - 如果要分配的对象的大小大于等于region大小的一半,则会被G1认为是巨型对象,每个巨型对象会单独占用一个region或多个连续的region(大小超过1个region的情况),G1在运行过程中会避免巨型对象的移动,因为移动巨型对象的内存复制成本很高。巨型对象绝大部分是数组对象,非数组对象的大小只和字段数量有关,几乎不会有类有如此多的字段。巨型对象按照分代划分也划分到老年代。
  • Free - 还没有分配过或回收完成的region,作为Free Region空闲region, Free Region可以转变为其他Region。

# G1 GC的运行周期

g1-cycles.png

G1在运行时,会分为多种运行模式。

  1. Young Only GC - 默认情况下,G1会进行young only gc,young only表明G1只会回收年轻代region且会回收全部的年轻代region,年轻代region目标数量(达到指定数量后发起young only gc)可以动态调整。
  2. Concurrent Marking Cycle - 随着Young only gc的运行,不断有对象从年轻代晋升到老年代,并且程序运行中也会不断分配humongous,老年代和humongous region内存占用达到一定阈值(InitiatingHeapOccupancyPercent),G1会发起Concurrent Marking Cycle并发标记周期,并发标记周期分为初始标记(Initial Marking)、并发标记(Concurrent Marking)、最终标记(Remark)、清理(Cleanup)多个阶段,并发标记周期的目的是对老年代进行标记、统计老年代region的存活对象、清理空region、计算collection set等。
  3. Mixed GC - Concurrent Marking Cycle结束后,G1会进行若干次Mixed GC,挑选上一步并发标记中计算出来回收效率最高(和存活对象占比有关)的若干个老年代region以及全部的年轻代region进行回收,回收达到一定次数或没有回收效率较高的老年代region后,会再次进入到Young Only GC阶段,如此往复。
  4. Full GC - 在G1运行过程中,如果出现一些异常情况,比如Young Only GC时,要晋升的存活对象没有可用的老年代region可以存放,则G1会回退到全暂停的Full GC,Full GC使用标记压缩方式回收全部堆内存,暂停时间最长。

# G1运行步骤

# Young Only GC

G1的Young Only GC要做的事情为

img.png

  • 计算要回收的region集合,Young Only GC要回收的是全部Young Region(Eden和Survivor)
  • 从GC Root开始,对存活对象进行对象图遍历标记
  • 对于存活对象,转移到survivor区域(或old region),修改引用来源,指向新地址
  • 移动完对象后,在原有位置的旧对象头中设置标记位表示已经转移,并且保存转移后的地址到对象头中,这样遇到已经移动过的对象就不会重复移动了,并且能够读取出移动后的位置修改引用。
  • 更新remembered set

img.png

进入safepoint后。G1就可以从GC ROOT开始遍历、移动存活对象了。

G1的遍历标记流程类似广度优先遍历,维护一个队列,先从一些初始节点开始,处理存活对象,遍历存活对象的引用关系,加入到任务队列中。

对于存活的对象,如果对象处于collection set中,G1会将其移动到survivor区域中(如果age超过晋升年龄会晋升到老年代),然后修改来源引用指向新地址。 然后G1会遍历该对象的引用类型字段,判断如果引用的对象在collection set中,则将这个引用放入到任务队列中。 如果不在collection set中,则需要更新维护remembered set。

处理完一个引用后,会在引用目标对象原位置的对象头mark word存储新地址,然后设置一个标记标识当前对象已经处理过了。 这样在下次有其他引用的任务要处理时,就能发现该对象已经处理了不用重复处理,并且能从mark word中读取出新地址来修改来源引用。

为了提高并行处理能力,G1每个gc worker线程会维护一个自己的任务队列,当本地队列中满了时会放到一个全局队列。 当某个gc worker完成自己的任务后,还会主动帮助其他gc worker处理任务(work steal),降低整体的gc耗时。

下图是young only中对gc root直接引用到的对象的处理过程。

img.png img.png

下图是对于广度优先搜索中的队列中的任务的处理过程,和gc root的处理基本一致。

img.png

# Safepoint

前面我们提到的对mutator的暂停,就和safepoint有关。

img.png

safepoint是jvm中的同步协调机制,当jvm希望执行一些操作,并且希望在执行这些操作过程中,其他的线程(mutator线程)处于暂停状态,就会使用safepoint。 gc、jstack、jmap、jcmd等命令都借助了safepoint机制。 jvm可以类比为加锁,存在进入safepoint,退出safepoint两种操作,在jvm希望进入safepoint时,会设置一个全局 标识,mutator线程在运行过程中不断(运行到特定类型的代码时)检查这个标识,如果发现要进入safepoint了,则会暂停自己的线程。 当所有的mutator线程都暂停后,jvm线程就可以执行gc等操作了,在safepoint中,由于不和mutator并发操作堆内存中的对象引用,避免了并发问题处理。

img.png

另外safepoint的一个重要功能是GC Root,mutator线程在运行过程中,每个线程都有自己的线程栈,线程栈是一个栈结构,每个栈帧中都包含 局部变量表、操作数栈,局部变量表和操作数栈中每个slot(槽位)存储的值的类型,有可能是引用、也有可能是数值(int、boolean等), 线程栈中的引用类型则需要作为GC Root用于对象图遍历。 hotspot jvm使用的是准确式gc,也就是不会错把一个数值类型的数据当成引用,这是通过在进入safepoint前,jvm生成gc map的方式实现的, gc map保存了当前线程栈的局部变量表、操作数栈中哪个位置是引用,这样gc过程中,jvm就能准确的找出所有的gc root进行遍历。 生成gc map存在性能和空间开销,为了降低开销,mutator只在特定的代码位置才会进入safepoint(方法进入、返回、uncounted loop backedge无界循环回边等jvm认为可能会长时间执行代码的位置)。

前面提到的准确式GC的优势是什么呢?因为G1 GC中使用复制算法对对象进行移动,并且修改来源引用,如果不准确比如把一个数值当做引用进行了移动,在修改引用值时就会 错误得修改对应的数值。而准确式GC只会修改引用,不会出现这种问题。

# remembered set

img.png

G1在Young Only GC和Mixed GC时,有一个特点,就是只会回收堆内存中的一部分区域,比如Young Only GC只回收Young Region。 这就为GC的实现带来了一些困难,因为要对对象图进行遍历。

  1. 如果遍历全部对象,则遍历耗时会随着堆内存(存活对象)变大而增大
  2. 如果不遍历老年代,则可能出现年轻代中存活对象漏标的情况,比如有老年代的存活对象指向一个年轻代的对象,这个对象也是存活对象。

img.png

为了解决这个问题,G1通过空间换时间(gc暂停时间)的思想进行了优化,G1为每个region保存了一个Remembered Set简称RemSet。 Remembered Set保存的是来自其他region(old region)到当前region的引用信息,即有哪些来源引用指向当前region。 为什么只记录来自old region的引用呢?因为每次gc时,无论是young only还是mixed,都会遍历全部的young region,所以young region对于其他region的 引用都会遍历到,不需要再记录。 引用数据会在G1中通过Write Barrier机制记录,Write Barrier能够在jvm执行引用代码过程中,出现引用修改的前后执行特定的代码, G1的修改引用后,会执行维护remset的代码,G1判断引用来自非年轻代(老年代)则会对将来源引用记录到被引用对象的region的remset中。

img.png

这是还会出现几个性能问题

在Write Barrier中同步修改remset可能导致应用代码执行变慢,为此G1会将数据相关写入到一个队列中,异步处理,并且为了降低线程间的冲突减少同步,会先将数据写入到线程本地队列中,本地队列满之后放到全局队列,后台有若干个gc线程负责消费这些数据

重复数据多、内存占用高,比如一个老年代的对象的引用字段,不断修改到另一个region中的对象,那么会在队列中产生大量重复数据。 为此G1做了两个优化,1是将数据以card维度记录,每个card表示512byte的内存范围;2是增加了一个card table,card table起到去重的作用, card table通过数组实现,数组的索引表示card(能够映射到堆内存中的512byte的范围),数组中的值是byte,其中0表示clean,1表示dirty,dirty指对应的 card已经放入到队列中了,G1在Write Barrier中会检查和修改card table,如果发现card table上对应的card value已经是dirty了则不需要重复入队。

G1通过N个ConcurrentRefineThread来处理全局队列中的card,并且根据card数量调节线程数量,在ConcurrentRefineThread处理不过来时, mutator也会参与到remset维护中。同时如果全局队列中的card比较少,ConcurrentRefineThread也不会处理,目的是保持一定的card table的dirty数量,用于去重(缓存)。

从队列中获取出来card后,还会保存一个HotCardCache用于记录热点card,对于热点card不会记录到remset中,而是在GC时单独处理。 不是热点的card,会先清理card table设置为clean,然后扫描对应card的内存范围,找出引用关系对,把每个引用关系对,把来源card到被引用对象所在的region的remset中。

img.png

每个Region的RemSet这个数据结构内部,通过多种粒度的存储来保存来源信息。 当card数量较少时,通过SparseTable稀疏表精确记录对应的region和card集合,可以理解为map<region, set<card>>; 当card数量变多时,G1开始把card较多的region转换为bitmap结构,可以理解为map<region, bitmap<card>,map的value即bitmap表示对应来源region中的哪些card中有指向当前region的引用 当card数量继续变多时,G1开始将一些region通过coarse map即粗粒度map存储,coarse map是bitmap,bitmap中某一个位有true,表示对应的region有引用。

下面是remset相关的代码

img.png img.png img.png

# Humongous回收

# Concurrent Marking Cycle

老年代(包括humongous)region不断增长,当占整个堆内存的比例超过一定阈值(InitiatingHeapOccupancyPercent,简称IHOP)后,G1会发起 Concurrent Marking Cycle并发标记周期。

这个检查时机发生在young only gc结束时或为humongous object分配内存时。

并发标记周期分为如下4个步骤

  1. 初始标记 Initial Mark
  2. 并发标记 Concurrent Mark
  3. 最终标记/重新标记 Remark
  4. 并发清理 Cleanup

# Initial Mark

初始标记的目的是为了给之后的并发标记构建初始的遍历节点,并发标记的目的是为了标记老年代中的存活对象。 所以初始标记会标记从GC root能够直接访问到的老年代的对象。

img.png

img.png

初始标记会通过发起一次young only gc(Concurrent Start)完成,特殊之处在于这次young gc的扫描gc root时,如果发现有从gc root 到老年代的引用,则会将对应的老年代对象保存到concurrent marking bitmap中。 concurrent marking bitmap是G1用于并发标记的数据结构,每个bit表示8byte的位置(因为hotspot jdk的对象地址使用8字节对齐), 并且G1中存在两个marking bitmap,一个prev一个next,next表示当前正在遍历标记的bitmap,prev表示已经遍历标记完的。 所以G1中marking bitmap会占用 堆内存大小 / 64 * 2 也就是堆内存/32的内存空间。

img.png

# Concurrent Mark

并发标记阶段并发标记线程和mutator并发执行

# SATB和TAMS

并发标记中的并发问题。 在并发线程运行过程中,mutator也在运行,这里可能出现并发问题导致存活对象被漏掉。

为了便于讨论,先学习一下gc领域的黑灰白三色标记。标记是指标记对应的对象为存活对象。

  • 黑色 - 该对象已经标记,且该对象的引用字段也都已经处理完或已经加到任务队列中
  • 灰色 - 该对象已经标记,但是对象的引用字段还没有处理完
  • 白色 - 该对象还没有标记

img.png

现在存在A, B, C三个对象,A是黑色,B是灰色,C是白色。 在时间点1,A引用了B,B引用了C。 在时间点2,mutator修改增加了A到C的引用、B删掉了到C的引用,且C没有来自其他对象的引用。 在时间点2,并发标记线程对灰色的B对象的字段进行处理,但是此时B已经删了到C的引用,A对象增加了对C的引用,但是A已经是黑色对象,标记线程不会再标记C对象。 最终C对象虽然有来自存活对象的引用,但是却没有被标记为存活对象,出现了漏标。

img.png

漏标出现说明出现了引用的删除,G1的解决方案是在引用修改时,增加了一个Write Barrier,比如把A的字段从旧的引用C改到了D,则会把C放入到一个SATB队列中。 并发标记线程也会从SATB队列中读出对象并标记到marking bitmap中。

satb是snapshot at the beginning的缩写,意思是在并发标记开始时存活的对象都认为是存活对象,及时标记过程中可能不再存活,比如如果前面的C没有得到A的引用,则 A应该是一个不存活的对象,但是也被标记为存活了,也就是存在一定的浮动垃圾,不过优点是不会出现漏标问题。

img.png

另外一个并发问题是,并发标记开始之后创建的对象,应该也是存活对象,G1为了解决这种问题,会在并发标记开始时,对每个region记录一个当前内存分配位置top的值,称为 TopAtMarkStart简称TAMS,在TAMS之上的对象都认为是存活对象。

# Remark

Remark阶段的作用是结束上一步的并发标记,因为mutator在不断修改堆中的对象,Remark会在safepoint中执行,所以能够暂停mutator, 把mutator线程本地的satb队列和全局satb队列中的待处理的对象遍历标记处理完,然后就完成了老年代的存活对象标记。 Remark过程最后还会查看老年代是否有空的region(即没有存活对象的老年代region),进行提前回收。

# Cleanup

cleanup阶段会和mutator并发执行,负责计算各个old region的回收效率 reclaimable_bytes() / region_elapsed_time_ms region的存活对象越少(可回收内存越多)、rembered set数量越少,回收效率越高。 然后按照回收效率排序计算后面几次Mixed GC中每次回收的region。

# Mixed GC

Concurrent Marking Cycle结束后,G1会先进行一次Young GC Before Mixed GC,目的是调整下Young Region的数量。 然后会进行N次的Mixed GC。 每次Mixed GC,会选择全部的Young Region和一部分Old Region进行回收。

回收的执行过程和Young Only GC基本一致。

# G1常用参数配置、介绍

  • InitialRAMPercentage - 和下面的Max一起控制堆内存的初始和最大大小占机器内存比例,适用于容器环境,建议配置成相同值,如果指定具体的值使用 -Xms和-Xmx
  • MaxRAMPercentage
  • MaxGCPauseMillis - 最大暂停时间,G1会尽量满足此配置,默认200
  • G1NewSizePercent - 年轻代最小比例,默认5
  • G1MaxNewSizePercent - 年轻代最大比例,默认60
  • G1ReservePercent - 为年轻代晋升保留的内存,默认10
  • G1UseAdaptiveIHOP - 自适应调节IHOP,默认开启
  • InitiatingHeapOccupancyPercent - 默认的IHOP,45,如果开始上面的自适应,会自动调节
  • G1HeapRegionSize - Region大小,默认通过堆内存计算,可以通过参数覆盖
  • ParallelGCThreads - 并行worker线程数量,比如Young Only GC时worker的数量
  • ConcGCThreads - 并发worker线程数量,比如Concurrent Marking线程数量,如果设置较多concurrent marking更快但可能和mutator争抢较多cpu资源
  • G1ConcRefinementThreads - 处理rem set的后台线程数量,默认等于ConcGCThreads

# GC日志

在jdk11即以上版本,GC的日志使用了新的配置方法。

启动时配置JVM参数

-Xlog:gc*=debug,safepoint=info:gc.log::filecount=1,filesize=100M
1

运行时可以通过jcmd动态配置gc日志

jcmd $pid VM.log output="file=/tmp/gc.log" output_options="filecount=5,filesize=10m" what="gc=debug" decorators="time,level"
1

参考 Unified-GC-Logging (opens new window)

# G1常见问题、分析解决方法

# FullGC、Mixed GC频繁

Mixed GC频繁一般发生在老年代存活对象较多,且关闭自适应调节IHOP即设置了-XX:-G1UseAdaptiveIHOP的情况,这种情况下 G1会使用固定的IHOP默认是45%(-XX:InitiatingHeapOccupancyPercent)。

  1. 调大堆内存
  2. 调高-XX:InitiatingHeapOccupancyPercent
  3. 不设置-XX:-G1UseAdaptiveIHOP
  4. 优化程序,通过histo或dump后通过idea的profiler或mat等工具查看对象内存占用,减少老年代存活对象的数量,比如通过jmap -histo查看排名靠前的类

# Young GC Mixed GC耗时高

Garbage-First Garbage Collector Tuning (opens new window)

# 设计总结

  • 异步延迟批量处理, remembered set维护,dirty card的延迟批量处理
  • 线程本地队列、异步处理、减少线程间冲突
  • remembered set空间换时间

# 更多参考资料