Java性能优化之JVM GC(垃圾回收机制)

您的点赞是我更新的动力,欢迎关注,免费答疑
有挺多大中小厂内推通道,正式和外包都有,欢迎找我内推

简介

在学习Java GC之前,我们需要了解一些背景信息。GC 是垃圾回收器的简称,全称是Garbage Collection。

Java 的垃圾回收器并不是特指一种,Java官方本身就提供了很多个GC回收器供用户选择,还有各个Java虚拟机厂商(例如 Azul 的PCG、C4)也自己设计开发了很多优秀的垃圾回收器。

Stop The World 也是一个很重要的关键词,它会在任何一种GC算法中发生,其实可以把它理解为JVM GC在清理内存时,整个程序的停顿时间。当 Stop The World 发生时,除GC所需的线程外,所有的线程都进入等待状态,直到 GC 任务完成。每一代的Java垃圾回收器,都把缩减 Stop The World 停顿时间作为很重要的目标。

这就像你在扫地的时候,会命令小孩和狗子呆在原地不准乱搞一样,不然一边在清理,一边又在制造新的垃圾,或者不小心把你扫成堆的垃圾踢散,垃圾就很难清扫干净了。
垃圾回收器,到目前为止,还没有出现一个适用于所有场景的完美方案,一招鲜吃遍天的回收器几乎不可能出现。这是一个三角形关系,由内存占用、吞吐量、停顿时间三者组成,互相拉扯。想内存占用少,吞吐量就低。想吞吐量高,内存占用也得提高。但内存占用大,标记和清理的停顿时间又会变长,这又会影响吞吐量......
所以,了解JVM GC的原理,可以了解各种GC回收器非常优秀的设计思路,也可以让我们以后在技术选型上,挑选符合自身需求的回收器。

看过 Java JVM 运行机制及基本原理 的小伙伴应该知道,不同的虚拟机厂商对于虚拟机的实现的细节各有不同,本文仅以 HotSpot 虚拟机展开,详解它的垃圾回收机制。


回收哪个区域?

JVM GC只回收堆区和方法区内的基本类型数据和对象。

栈区的数据(仅指基本类型数据),在超出作用域后会自动出栈释放掉,所以其不在JVM GC的管理范围内。


怎么判断对象可以被回收了?

简单来说就是:对象没有引用了或者对象不可达

怎么判断对象是否存活?常见的有两种算法,分别是 引用计数法 和 可达性分析法

引用计数法

在对象里添加一个被引用的计数器,每当有地方引用了它,计数器就加1,引用失效时,计数器就减1。

在触发回收内存的时候,遍历所有对象,把计数器值等于0的找出来,释放掉即可。

看起来原理很简单,判断效率也不错对吧?但是它有个问题,无法回收互相引用的对象!举个栗子:

static class Test{
    public Test instance;
}

public void run() {
    Test t1 = new Test();
    Test t2 = new Test();
    t1.instance = t2;
    t2.instance = t1;
}

可以看到,t1 的 instance 赋值了 t2,t2 的 instance 又赋值了 t1,实际上运行完成 run() 方法后,t1 和 t2 都已经不可能再被访问,但由于它们互相引用对方,引用计数都不等于0,也就没办法对他们进行回收。

所以,市面上主流的Java虚拟机都没有使用这个算法,而是使用可达性分析法做为判断对象是否存活的算法。

可达性分析法(根搜索算法)

其实不止是Java,C# 也是使用可达性分析算法来判断对象是否存活的,这个算法也可以称之为根搜索算法。

这个算法的基本原理是通过一系列可被作为 GC Roots 的根对象来作为起始节点,从这些节点开始,根据引用关系向下搜索,搜索过程的就是一条引用链(Reference Chain),没有在这个链条上面的对象,也就是根节点通过引用链不可达到这个对象时,就认为这个对象是可以被回收的。


哪些对象可以作为根节点呢?

在虚拟机栈帧中引用的对象,例如线程调用方法时,使用或产生的参数、局部变量、临时变量等。
在方法区中,类的引用类型静态变量或常量。
在本地方法栈中的JNI引用的对象,
在JVM内部的对象,例如基本数据类型的Class对象,一些常驻的异常对象(NullPointExcepiton),系统类加载器等。
所有synchronized同步锁的持有对象。
反映JVM内部情况的JMXBean、JVMTI注册的回调、本地代码缓存等。
......


可达性分析法的示例图

你看,使用可达性分析法,就不存在相互引用的问题了。


总结

Java目前在用的主流虚拟机,都是采用可达性分析法来判断对象是否可被回收的,它通过若干个根节点组成的集合(GC Roots),向下遍历搜索,遍历的过程就是一条引用链,没有在这个链条上面的对象,是不可能被再次使用的,可以判定为可回收的对象。


JVM GC什么时候执行?

当程序创建一个新的对象或者基本类型的数据,内存空间不足时,会触发GC的执行。

不同的垃圾回收器,会有不同的回收策略,但大致可以分为两类:分代回收和局部回收两种策略,接下来我会详细讲解这两种策略,请接着往下看。


分代回收机制

大多数的商业虚拟机,都采用分代回收的理论来设计垃圾收集器,这个理论建立在两个分代假说上:

弱分代假说:绝大多数对象都是朝生夕死的。
强分代假说:熬过越多次的垃圾回收的对象,就越难消亡

既然绝大多数对象都熬不过几次垃圾回收,而熬过多次回收的对象又很难消亡,那么可以根据年龄把它们划分到不同的区域,例如新生代区域和老年代区域,然后分而治之。

例如新生代,绝大多数对象都是朝生夕死的,每次触发GC,这个区域里大部分对象都会被回收,非常适合使用可达性分析法,因为从根节点顺着引用链遍历下去,只有在这个引用链上的才是存活的,假设本次触发GC,这个区域里90%的对象都要被回收,但实际上只需要关注引用链上10%的对象就可以了,使用复制算法把这10%移动到一个幸存者区域,剩下的直接释放即可。

对于熬过很多次依然存活的对象,这种对象一般很难被回收了,这样的情况下,每次GC都对他们进行搜索标记,太浪费资源。把它们放到老年代区,这样JVM就能以较少的频率来回收这个区域,假如老年代的空间占比是60%,在不触发老年代回收的情况下,只需要对占比40%内存空间的新生代进行搜索和释放,效率提升还是很明显的!


各区域触发垃圾回收的类型与解释:

Minor GC:只回收新生代区域。
Major GC:只回收老年代区域。只有CMS实现了Major GC,所以在老年代里,触发GC,除了CMS和G1之外的其他收集器,大多数触发的其实是 Full GC
Full GC:回收整个堆区和方法区
Mixed GC:回收整个新生代和部分老年代。G1收集器实现了这个类型。


新生代(Young generation)

绝大多数新创建的对象都会被分配到这里,这个区域触发的垃圾回收称之为:Minor GC

空间结构:

默认情况下,新生代(Young generation)、老年代(Old generation)所占空间比例为 1 : 2 。

它被分成三个空间:

· 1个伊甸园空间(Eden)

· 2个幸存者空间(Fron Survivor、To Survivor)

默认情况下,新生代空间的分配:Eden : Fron : To = 8 : 1 : 1

为什么要这样的布局?是因为新生代里的对象绝大多数是朝生夕死的,非常适合使用标记-复制算法,后面的回收算法章节会详细说。


新生代GC收集的执行顺序如下:

1、绝大多数新创建的对象会存放在伊甸园空间(Eden)。

2、在伊甸园空间执行第 1 次GC(Minor GC)之后,存活的对象被移动到其中一个幸存者空间(Survivor)。

3、此后每次 Minor GC,都会将 Eden 和 使用中的Survivor 区域中存活的对象,一次性复制到另一块空闲中的Survivor区,然后直接清理 Eden 和 使用过的那块Survivor 空间。

4、从以上空间分配我们知道,Survivor区内存占比很小,当空闲中的Survivor空间不够存放活下来的对象时,这些对象会通过分配担保机制直接进入老年代。

5、在以上步骤中重复N次(N = MaxTenuringThreshold(年龄阀值设定,默认15))依然存活的对象,就会被移动到老年代。

从上面的步骤可以发现,两个幸存者空间,必须有一个是保持空的

我们需要重点记住的是,新创建的对象,是保存在伊甸园空间的(Eden)。那些经历多次GC依然存活的对象会经由幸存者空间(Survivor)转存到老年代空间(Old generation)

也有例外出现,对于一些大的对象(指需要占用大量连续内存空间的对象)则直接进入到老年代。
Java提供了 -XX:PretenureSizeThreshold 来指定对象大于这个值,直接分配到老年代。


老年代(Old generation)

对象在新生代周期中存活了下来的,会被拷贝到这里。通常情况下这个区域分配的空间要比新生代多。正是由于对象经历的GC次数越多越难回收,加上相对大的空间,发生在老年代的GC次数要比新生代少得多。这个区域触发的垃圾回收称之为:Major GC 或者 Full GC

老年代空间的构成其实很简单,它不像新生代空间那样划分为几个区域,它只有一个区域,里面存储的对象并不像新生代空间里绝大部分都是朝闻道,夕死矣。这里的对象几乎都是从Survivor 空间中熬过来的,它们绝不会轻易狗带。因此,Major GC 或 Full GC 发生的次数不会有 Minor GC 那么频繁。


为什么老年代的回收耗时,比新生代更长呢?

有两点原因:

1、老年代内存占比更大,所以理论上回收的时间也更长
2、老年代使用的是标记-整理算法,清理完成内存后,还得把存活的对象重新排序整理成连续的空间,成本更高(算法的细节,后续章节会详细说。)


方法区(Method area)

这个区域主要回收废弃的常量和类型,例如常量池里不会再被使用的各种符号引用等等。类型信息的回收相对来说就比较严苛了,必须符合以下3个条件才会被回收:

1、所有实例被回收
2、加载该类的ClassLoader 被回收
3、Class 对象无法通过任何途径访问(包括反射)

可以使用 -Xnoclassgc 禁用方法区的回收。


跨代引用的问题

举个栗子,新生代中的对象很有可能会被老年代里的对象所引用,当新生代触发GC的时候,只搜索新生代的区域明显是不够的,还得搜索老年代的对象是否引用了新生代中非 GC Roots 引用链上的对象,来确保正确性。但这样做会带来很大的性能开销。为了解决这个问题,Java定义了一种名为记忆集的抽象的数据结构,用于记录存在跨区域引用的对象指针集合。

大多数的虚拟机,都采用一种名为卡表(Card Table)的方式去实现记忆集,卡表由一个数组构成,每一个元素都对应着一块特定大小的内存区域,这块内存区域被称之为卡页(Card Page),每一个卡页,可能会包含N个存在跨区域引用的对象,只要存在跨区域引用的对象,这个卡页就会被标识为1。当GC发生的时候,就不需要扫描整个区域了,只需要把这些被标识为1的卡页加入对应区域的 GC Roots 里一起扫描即可。


回收算法讲解

标记 - 清除算法

这个算法和它的名字一样,分两个步骤:标记 和 清除。首先标记出所有存活的对象,再扫描整个空间中未被标记的对象直接回收。

并没有规定标记阶段一定要标记“存活”的对象,也可以标记“可回收”的对象
标记“存活”的,还是标记“可回收”的,网上各种说法都有,我个人理解,是标记存活的。这样效率高些。
首先,Java使用的是可达性分析算法来判断对象是否存活,上面有详细说这个算法,这里就不重复了。
我们假设要标记“可回收”的对象,再进行清除,那么需要三个步骤:
1、先通过可达性分析法,通过根对象(GC Roots)顺着引用链先把这些存活对象都标出来
2、遍历这个区域所有对象,把没标记存活的对象,打上一个“可回收”的标记
3、遍历这个区域所有对象,把标记了“可回收”的对象,释放掉。
但标记的是“存活”的对象,再进行清除,只需要两个步骤即可:
1、先通过可达性分析法,通过根对象(GC Roots)顺着引用链先把这些存活对象都标出来
2、遍历这个区域所有对象,把没标记存活的对象,直接清理掉即可。
所以,标记“可回收”的对象,会多了一次完全没有必要的遍历。这也是我不认同标记“可回收”的原因。

标记 - 清除算法由于回收后没有进行整理的操作,所以会存在内存空间碎片化的问题,这个确实是缺点,但也是这个算法的特点,正因为它不进行整理,所以效率才高。


标记 - 复制算法

常规的复制算法,是把内存分成两块大小相同的空间(1 : 1),每次只使用其中一块,当使用中的这块内存用完了,就把存活的对象移动到另一块内存中,再把使用过的这块内存空间一次性清理掉。这个做法虽然效率极高,但也浪费了一半的内存空间。

标记-复制算法,在这个基础之上对其进行了优化,IBM曾有过一项针对新生代的研究,结论是绝大多数情况下,新生代区域里的对象有98%都熬不过第一次回收。

所以不需要按照 1 : 1 的比例来实现复制算法,而是可以按照 8 : 1 : 1 的比例来分配内存空间,也就是一个80%的Eden空间和两个10%的Survivor空间。

为什么要两块Survivor空间?
因为复制算法,必须要有一块空间是空闲的。想象一下,如果只有一块Eden空间 + 一块Survivor空间
当GC回收完成后,Eden中存活的对象会移动到Survivor空间。程序继续运行,新的对象又会进入Eden空间,此时就会出现 Eden 和 Survivor 空间里都有对象,复制算法也就进行不下去了。

每次分配内存,只使用Eden和其中一块Survivor空间,发生GC回收时,把Eden和其中一块Survivor空间中存活的对象,复制到另一块空闲的Survivor空间,然后直接把Eden和使用过的那块Survivor空间清理掉。

目前主流的使用分代回收机制的Java虚拟机,都是使用标记-复制算法来作为新生代的回收算法。它非常适合用在新生代这种回收率极高的场景,这样的场景下,复制算法浪费的空间几乎可以忽略不计。效率高,且内存不会有碎片化的问题。但对于老年代这种存活率很高的场景,就不适合了。

标记-复制算法还有一个非常重要的知识点,就是分配担保机制,虽然根据IBM的研究,每次GC新生代里98%的对象都会被回收,但这不是百分之百的几率,极端情况下可能会出现超过10%的对象存活。分配担保机制就是为了保证当出现这种情况时,有其他内存空间来进行兜底。通常这个“担保人”是老年代,当存活的对象超过Survivor空间大小时,这些存活的对象会忽略年龄,直接进入老年代里。


标记 - 整理算法

标记-清除算法会产生内存碎片,不适合哪些需要大量连续内存空间的场景,而标记-整理算法,就是在其基础之上,增加了整理这个操作,去解决这些内存空间碎片化的问题,如下图所示:

和标记-清除算法一样,先标记,但清除之前,会先进行整理,把所有存活的对象往内存空间的左边移动,然后清理掉存活对象边界以外的内存,即完成了清除的操作。标记-整理 算法是在 标记-清除 算法之上,又进行了对象的移动排序整理,因此成本更高,但却解决了内存碎片的问题。

老年代里的对象存活率很高,不适合使用标记-复制的算法。而且老年代存储大对象的概率要比新生代大很多,这些大对象需要连续的内存空间来存储,标记-清除这个算法也不适合。所以大多数的老年代都采用标记-整理来作为这个区域的回收算法。


Q & A

为什么老年代不使用和新生代一样的标记-复制算法呢?

新生代里绝大多数对象都是朝生夕死的,使用的标记-复制算法,空间占比可以8 : 1 : 1,但是老年代里对象存活率很高,这个占比明显不合适。如果占比得设置得大 (例如50%),又会浪费很多内存空间,而且由于对象很多都是存活的,复制移动也是一笔开销。所以标记-复制这个算法,不适合老年代这种对象存活率很高的区域。


标记和根搜索算法是什么样的关系?

Java使用的是根搜索(可达性分析)算法来确定对象是否存活的,而不是引用计数法这种事先在对象里记录引用数的做法。
标记其实不用遍历整个内存空间(除非内存空间里的对象全部存活),而是通过根搜索算法顺着引用链遍历标记存活的对象。所以标记的过程,就是根搜索算法查找存活对象的过程。


标记-整理算法,每次整理都消耗大量时间,能不能优化一下?

可以的,每次回收后,都进行整理,确实会消耗太多的资源。可以通过设置一个阈值或者临界点,当内存碎片化程度还在这个阈值范围内的时候,仅采用标记-清除算法。只有超过这个阈值,才进行整理。


什么是内存碎片?它会带来什么问题?

从上面 标记-清除 算法,我们看到回收完成后,会产生很多不连续的内存空间,这就是内存碎片。
Java虚拟机对于大对象(例如很长的字符串、byte数组等等),都必须存储在连续的内存空间里,当一个大对象需要进入某个内存空间时,由于内存碎片过多,虽然剩余内存是远大于这个对象所需空间的,但就是找不到一块连续的内存空间来存储它,这会导致提前触发一次Full GC。


常用的垃圾回收器

每一个回收器都存在Stop The World 的问题,只不过各个回收器在Stop The World 时间优化程度、算法的不同,可根据自身需求选择适合的回收器。
目前应用范围最广的,应该还是JDK8,它默认使用的是 Parallel Scavenge + Parallelo Old 收集器组合。


Serial(-XX:+UseSerialGC)

Serial 是Java虚拟机初代收集器,在JDK1.3之前是Java虚拟机新生代收集器的唯一选择,这是一个单线程工作的收集器。在进行垃圾回收的时候,需要暂停所有的用户线程,直到回收结束。

虽然历史久远,但它依然是HotSpot虚拟机运行在客户端模式下,或者4核4GB以下服务端的默认新生代收集器,这种核心数和内存空间较小的场景下,它单线程的优势就体现出来了,没有线程交互的开销,加上内存空间不大,单次回收耗时几十毫秒,这点停顿时间,完全是可以接受的。

Serial 负责收集新生代区域,它采用标记-复制算法。


Serial Old(-XX:+UseSerialOldGC)

SerialOld 是 Serial 收集器的老年代版本,和 Serial 一样,它也是单线程的收集器。目前主要应用在客户端模式(Client VM)下的HotSpot虚拟机使用。

如果在服务端模式(Server VM)下,它也有两种用途:一个是在JDK5以及之前,和Parallel Scavenge收集器搭配使用,另外一个就是作为CMS收集器在出现并发模式故障(Concurrent Mode Failure) 时作为后备收集器。

SerialOld 负责收集老年代区域,它采用标记-整理算法。


ParNew(-XX:+UseParNewGC)

随着计算机的核心数和内存容量都在飞速发展,多核心和大内存容量的场景下,Serial 收集器单线程的性能明显比较落后了,ParNew 就是 在Serial 收集器的基础之上,实现了它的多线程版本。它可以多条线程同时进行垃圾收集,这也是它和 Serial 收集器的最大的区别,其他的功能性、配置、策略等等的和 Serial 基本一致。

ParNew有一个比较重要的知识点,在JDK9之后,Java官方取消了ParNew和除了CMS收集器之外的所有老年代收集器的搭配,而且还取消了 - XX:+UseParNewGC 这个参数。所以JDK9之后,ParNew只能和CMS搭配使用了。

ParNew 负责收集新生代区域,它采用标记-复制算法。

ParNew 是JDK7之前 Server VM 模式下的首选的新生代收集器。但是在单CPU的情况下,它的效率不会比 Serial收集器高的,所以要注意使用场景。


Parallel Scavenge(-XX:+UseParallelGC)

Parallel Scavenge 从外观上看,和 ParNew 很相似,都是新生代的收集器,支持多线程并行回收,也同样是使用标记-复制来作为回收算法。但 Parallel Scavenge 的关注点不一样,它的目标是实现一个可控制吞吐量的垃圾收集器。

吞吐量的计算公式:运行用户代码时间 / (运行用户代码时间 + 运行垃圾收集时间)

假设运行用户代码时间是 99 分钟,运行垃圾收集时间是 1 分钟,结合计算公式 :吞吐量 = 99 / (99 + 1) = 0.99,也就是 99% 的吞吐量。

Parallel Scavenge 收集器提供了一些参数,给用户按自身需求控制吞吐量:

-XX:MaxGCPauseMillis
控制垃圾收集停顿的最大时间,单位是毫秒,可以设置一个大于0的数值。
不要想着把这个数值设置得很小来提升垃圾收集的速度,这里缩短的停顿时间是以牺牲新生代空间大小换来的,空间小,回收自然就快,停顿时间自然也短,但是空间小,吞吐量自然也会小。所以得综合考虑。

-XX:GCTimeRatio
设置垃圾收集时间占比的计算因子,参数范围是0 - 100的整数。它的公式是 1 / (1+GCTimeRatio)
举个栗子:当设置成15,那就是 1 / (1+15) = 0.0625,就是允许最大垃圾收集时间占总时间的6.25%,当设置成99的时候,就是 1 / (1+99) = 0.01,也就是允许最大垃圾收集时间占总时间的1%,依次类推。

-XX:+UseAdaptiveSizePolicy
动态调整开关,这个参数和 Parallel Scavenge 收集器无关,但是搭配起来使用是一个很好的选择。
当这个参数被激活,就不需要人工指定新生代的大小、Eden和Survivor区的比例、对象直接进入老年代的大小等等细节参数了,JVM会根据当前运行的情况动态调整,给出最合适的停顿时间和吞吐量。搭配以上两个参数,和把基本的内存数据设置好即可,例如堆的最大占用空间等等。


Parallel Old(-XX:+UseParallelOldGC)

就像 Serial Old 是 Serial 的老年代版本一样,Parallel Old 是 Parallel Scavenge 的老年代版本。

Parallel Old 也支持多线程并行回收的能力,使用标记-整理来作为回收算法。这个收集器是JDK6的时候推出的,和 Parallel Scavenge 搭配,在多CPU核心和大内存的场景下,吞吐性能优秀。

在注重吞吐量和多CPU核心的情况下,都可以优先考虑 Parallel Scavenge + Parallelo Old 收集器,这也是JDK8默认的垃圾收集器组合


CMS (-XX:+UseConcMarkSweepGC)

CMS(Concurrent Mark Sweep) 是JDK1.4后期推出的GC收集器,它是一款并发低停顿的收集器,对于响应速度有较高要求,对停顿时间忍受度低的应用,非常适合使用CMS作为垃圾收集器。

CMS 负责收集老年代区域,它采用标记-清除算法。

它的运行过程相对于前几个来说会复杂一些,可以分为四个步骤:

1、初始标记(CMS initial mark)

这个阶段需要 Stop Tow World(暂停暂停所有用户线程),但这个阶段的速度很快,因为只标记和根节点(GC Roots)直接关联的对象。

2、并发标记(CMS Concurrent mark)

这个阶段不需要 Stop Tow World,在初始标记完成后,并发标记从GC Roots直接关联的对象开始,遍历整个引用链,这个阶段耗时较长,但用户线程可以和GC线程一起并发执行

3、重新标记(CMS remark)

这个阶段需要 Stop Tow World,因为并发标记阶段,用户线程和标间线程同时在运行,相当于一边扫地一边丢垃圾,重新标记就是修正用户线程继续运行,导致的变动的那一部分对象。这一阶段的耗时比初始标记长一些,但远没有达到并发标记阶段那么长的时间。这个阶段可以多线程并行标记。

4、并发清理(Concurrent sweep)

这个阶段不需要 Stop Tow World,执行到这里,说明标记阶段已经完成,此时遍历整个老年代的内存空间,清理掉可回收的对象,由于不需要移动整理存活的对象,这个阶段可以允许用户线程和回收线程并发执行。在清理完成后,会重置CMS收集器的数据结构,等待下一次垃圾回收。

以上4个步骤可以看出,CMS之所以能实现低延迟,是因为它把垃圾搜集分成了几个明确的步骤,在一些耗时较长的阶段实现了用户线程和GC线程并发执行的能力。用两次短暂的 Stop Tow World 来代替了其他收集器一整段长时间的 Stop Tow World

CMS确实是非常优秀的垃圾收集器,但它也是有缺点的:

1、内存碎片。由于使用了 标记-清理 算法,回收结束后会产生大量不连续的内存空间,也就是内存碎片。

2、GC进行时会降低吞吐量。由于使用了并发处理,很多情况下都是GC线程和应用线程并发执行的,GC线程肯定会占用一部分计算资源,这个期间会降低一部分吞吐量(尽管这样,也比之前几个收集器好很多)。

3、浮动垃圾。CMS有两个阶段是可以用户线程和GC线程并发执行的,用户线程的继续执行自然会伴随垃圾的不断产生,这些就是浮动垃圾。这些垃圾只能等下次触发GC的时候才能清除了,也因为这些浮动垃圾的存在,CMS收集器需要留一手,JDK5的时候,在老年代内存空间使用了68%的时候就会触发一次GC,到了JDK6,觉得JDK5的这个设置太保守了,所以调整到了92%。

可以通过-XX:CMSInitiatingOccupancyFraction 调整这个阈值


Garbage First(G1)

G1 是 Garbage First 收集器的简称,它在JDK7的时候立项,JDK8 Update 40的时候才全部完工。这个收集器在JDK9 的时候成为了服务端模式下的默认垃圾收集器。

G1 收集器的设计理念是:实现一个停顿时间可控的低延迟垃圾收集器

G1 依然遵循分代回收的设计理论,但它对堆(Java Heap)内存进行了重新布局,不再是简单的按照新生代、老年代分成两个固定大小的区域了,而是把堆区划分成很多个大小相同的区域(Region),新、老年代也不再固定在某个区域了,每一个Region都可以根据运行情况的需要,扮演Eden、Survivor、老年代区域、或者Humongous区域。

大对象会被存储到Humongous区域,G1大多数情况下会把这个区域当作老年代来看待。如果对象占用空间超过Region的容量,就会存放到N个连续的 Humongous Region 中。

G1 收集器的内存空间结构

收集器的运行过程可以大致分成四个步骤:

初始标记(Initial Marking)- Stop Tow World

只标记 GC Roots 能直接关联的对象,还有一些额外的细节操作例如修改TAMS指针的值,保证后续阶段用户程序并发运行的时候,新对象分配在正确的位置。这个阶段需要暂停用户线程,但耗时很短。

并发标记(Concurrent Marking)- No Stop Tow World

从根节点(GC Root)开始,顺着引用链遍历整个堆,找出存活的对象。这个步骤耗时较长,但用户线程可以和GC线程并发执行。

最终标记(Final Marking)- Stop Tow World

处理并发标记阶段,用户线程继续运行产生的引用变动,这个阶段需要暂停用户线程,支持并行处理。

筛选回收(Live Data Counting and Evacuation)- Stop Tow World

根据以上三个阶段标记完成的数据,计算出各个Region的回收价值和成本,再根据用户期望的停顿时间来决定要回收多少个Region。回收使用的是复制算法,把需要回收的这些Region里存活的对象,复制到空闲的Region中,然后清理掉旧Region全部空间。因为需要移动存活的对象,所以不可避免的要暂停用户线程,这个步骤支持多条线程并行回收。

Q & A

设置停顿时间的参数是什么?

-XX:MaxGCPauseMillis 默认值是 200 毫秒


G1收集器是怎么保证停顿时间可控的?

首先G1把内存区域分成了若干个相同大小的 Region 区,在执行回收的时候,根据标记阶段统计到的数据,计算出各个 Region 区的回收价值和成本,有了这些数据之后,就可以计算出回收哪几个Region价值最高,且符合用户预期的停顿时间。
编辑于 2023-02-07 23:05・IP 属地广西