G1 垃圾回收器的理论、使用、优化
前言
这篇文章主要介绍G1(Garbage First)垃圾回收,以及一些机制、问题等,有一些专有名词不太清楚的可以看看对垃圾回收相关知识点又有介绍。
G1 垃圾回收器
1. 概述
G1
是在JDK 7 Update4 移除Experimental
标识的,他被Oracle 官方称为全功能的垃圾回收器
。 在整体上看采用的是标记-整理
算法,但是从局部(两个region之间)看有时基于标记-复制
算法实现。无论如何,这两种算法都意味着G1运作期间不会产生内存 空间碎片,垃圾收集完成之后能提供规整的可用内存。
2. 引入概念
-
region
:是把连续的Java堆划分为多个大小相等的独立区域,取值范围在1~32M,最多为2048 个Region. -
Humongous区域
: 专门存储大对象的区域,G1认为只要大小超过了一个 Region容量一半的对象即可判定为大对象。而对于那些超过了整个Region容量的超级大对象, 将会被存放在N个连续的Humongous Region之中,G1的大多数行为都把Humongous Region作为老年代 的一部分来进行看待。
3. 停顿可控原理(设计思路)
G1收集器之所以能建立可预测的停顿时间模型,是因为它将Region作 为单次回收的最小单元
,即每次收集到的内存空间都是Region大小的整数倍,这样可以有计划地避免 在整个Java堆中进行全区域的垃圾收集。更具体的处理思路是让G1收集器去跟踪各个Region里面的垃 圾堆积的“价值”大小,价值即回收所获得的空间大小以及回收所需时间的经验值,然后在后台维护一 个优先级列表,每次根据用户设定允许的收集停顿时间(使用参数-XX:MaxGCPauseMillis指定,默 认值是200毫秒),优先处理回收价值收益最大的那些Region,这也就是“Garbage First”名字的由来
。这种使用Region划分内存空间,以及具有优先级的区域回收方式,保证了G1收集器在有限的时间内获 取尽可能高的收集效率。
4. 特点
-
把Java 堆内存拆分为多个大小相等的Region; -
在逻辑上还是存在新生代和老年代的概念,但是新老年代是由一系列region 组成的; -
新生代里也划分了Eden 和Survivor,Region个数比不在是固定的:Eden: Survivor1: Survivor2=8:1:1,而是算法动态控制的; -
用户可以设置一个垃圾回收预期停顿时间; -
额外维护空间占用更大。每个region 都有一份自己卡表,可能会占整个堆内存的20% 或者更多。 -
G1 使用写前屏障跟踪并发时指针变化,写后屏障维护卡表。
5. 使用
通过-XX:UseG1GC
指定,默认会将堆内存除以2048
得出每一个Region的大小。刚启动时默认新生代对堆内存的占比5%
可以通过-XX:G1NewSizePercent
来制定新生代初始占比。在系统的运行过程中,新生代region占比不会超过60%
可以通过-XX:G1MaxNewSizePercent
指定。一旦进行了垃圾回收新生代的Region 还会减少。
-
计算
4096M对空间,每个region 大小2M(4096/2048)
,初始内存使用204.8M(4096*0.05)
约为100Region,最多 Region 总大小有2457M(4096*0.6)
,1228个,到了60% 会触发新生到的GC。
-
对象什么时候进入老年代
-
达到一定年龄的对象进入老年代; -
动态年龄判断规则; -
大对象(Humongous区域 作为大对象处理)。
6. 回收过程
G1 混合垃圾回收大致可分为四个步骤:初始标记、并发标记、最终标记、筛选回收。
-
初始标记
仅仅只是标记一下GC Roots能直接关联到的对象,
并且修改TAMS(Top at mark start) 指针的值
,让下一阶段用户线程并发运行时,能正确地在可用的Region中分配新对象。这个阶段需要 停顿线程,但耗时很短,而且是借用进行Minor GC的时候同步完成的,所以G1收集器在这个阶段实际 并没有额外的停顿。 -
并发标记
从GC Root开始对堆中对象进行可达性分析,递归扫描整个堆 里的对象图,找出要回收的对象,这阶段耗时较长,但可与用户程序并发执行。当对象图扫描完成以 后,还要重新处理SATB记录下的在并发时有引用变动的对象。 -
最终标记
对用户线程做另一个短暂的暂停,用于处理并发阶段结束后仍遗留 下来的最后那少量的SATB记录。 -
筛选回收
负责更新Region的统计数据,对各个Region的回 收价值和成本进行排序,根据用户所期望的停顿时间来制定回收计划,可以自由选择任意多个Region 构成回收集,然后把决定回收的那一部分Region的存活对象复制到空的Region中,再清理掉整个旧 Region的全部空间。这里的操作涉及存活对象的移动,是必须暂停用户线程,由多条收集器线程并行完成的。
7. 新生代+老年代混合回收(MixGC)
-
触发条件
老年代占据内存的45% 的region 时,会尝试触发一个新老年代的混合回收。可以通过
-XX:InitiatingHeapOccupancyPercent
进行控制,默认45%; -
混合回收特点
-
面向堆内存任何部分来组成回收集(Collection Set,一般简称CSet)进行回收,衡量标准不再是它属于哪个分代,而是哪块内存中存放的垃圾数量最多,回收收益最大。
2. 混合回收阶段你不是一次性收集完预期规定的垃圾的,而是反复收集,直到回收到预期目标之下,默认反复收集8次,通过-XX:G1MixedGCCountTarget
控制。 -
回收的region 里面的存活对象要低于一个值,默认是85%,通过 -XX:G1MixedGCLiveThresholdPercent
控制。 -
退出条件
堆中大于5% 的region 就不会进行混合回收,通过
-XX:G1HeapWastePercent
控制,默认5%; -
回收失败
G1在对象复制/转移失败或者没法分配足够内存(比如巨型对象没有足够的连续分区分配)时,会触发FullGC。FullGC使用的是stop the world的单线程的
Serial Old
模式,所以一旦触发FullGC则会STW应用线程,并且执行效率很慢。JDK 8版本的G1是不提供Full gc的处理的。对于G1 GC的优化,很大的目标就是没有FullGC。
8. G1 与CMS 垃圾回收器对比
-
G1优点
-
整体 标记-整理
算法,局部(两个region)上又是基于标记-复制
算法,全局还是局部都不会产生内存空间碎片,有利于长时间运行; -
采用单个region 内存布局能单个回收region,在 筛选回收
阶段会统计region,根据每个region的回收价值排序,从而 停顿时间可控。 -
缺点
-
G1 垃圾收集产生的内存占用:G1 的卡表实现更为复杂,而且每个Region 中都有一份卡表记录自己被那些 Region 指向,这导致 记忆集
可能会占堆容量的20% 乃至更多内存; CMS的卡表相对简单,只有唯一一份,而且只需要处理新、老年代的引用。 -
程序运行时的额外执行负载都比CMS 要高:都使用到写屏障,CMS用写后屏障来更新维护卡表;而G1除了使用写后屏障来进行 同样的(由于G1的卡表结构复杂,其实是更烦琐的)卡表维护操作外,为了实现原始快照搜索 (SATB)算法,还需要使用写前屏障来跟踪并发时的指针变化情况。G1类似消息队列的结构,把写前和写后屏障都放到队列里,然后异步处理。
-
应用 小内存使用CMS 的表现大概率由于G1,在大内存上应用G1 则大多能发挥其优势,一般在6G到8G以下使用CMS ,以上使用G1,G1最大内存不超过64G;
9. G1 问题
-
Region 里面存在的跨Region 应用对象如何解决?
-
在并发标记阶段如何保证收集线程与用户线程互不干扰地运行?
-
怎样建立起可靠的停顿预测模型?
G1收集器的停顿预测模型是以
衰减均值(Decaying Average)
理论基础来实现的,在垃圾收集过程中,G1收集器会记录每个Region的回收耗时、每个Region记忆集里的脏卡数量等各个可测量的步骤花费的成本,并分析得出平均值、标准偏差、置信度等统计信息。
这里强调的“衰减平均值”是指它会比普通的平均值更容易受到新数据的影响,平均值代表整体平均状态,但衰减平均值更准确地代表“最近的”平均状态。换句话说,Region的统计状态越新越能决定其回收的价值。然后通过这些信息预测现在开始回收的话,由哪些Region组成回收集才可以在不超过期望停顿时间的约束下获得最高的收益。 -
如何优化G1?
-
不要手动设置新生代和老年代的大小,只设置这个堆的大小。因为G1收集器在运行过程中,会自己调整新生代和老年代的大小 其实是通过adapt代的大小来调整对象晋升的速度和年龄,从而达到为收集器设置的暂停时间目标, 如果手动设置了大小就意味着放弃了G1的自动调优。 -
不断优化暂停目标时间。一般情况下这个值设置到100ms或者200ms, 暂停时间设置的太短,就会导致出现G1跟不上垃圾产生的速度。最终退化成Full GC。所以对这个参数的调优是一个持续的过程,逐步调整到最佳状态。暂停时间只是一个目标,并不能总是得到满足
由于篇幅有限,感兴趣的看官可以自行翻阅资料,推荐:深入理解Java虚拟机:JVM高级特性与最佳实践(第3版)周志明.pdf;如有不妥之处,还望看官指正,共同讨论,谢谢大家。