JVM的垃圾回收器

我们正处在一个时代的转型期，也就是从物理机到虚拟机再到云时代的转型期，目前正是多代并存的历史节点，也就是在实际生产环境中既有使用传统的物理服务器的业务，也有使用虚拟机的业务，更有已经大规模迁移到云平台的业务。

底层基础设施变迁，对我们如何使用 JVM 也在产生着潜移默化的影响。而 New Relic 最新发布的 2023 年的报告给我们指明了一个方向。报告中指出在 JDK 11 及以上的版本中，G1 一骑绝尘，使用率占比达到 65% 。

垃圾回收器全景图：

image.png

从图中可以看出，G1 之前每个垃圾收集器一般只是负责新生代或老年代的垃圾回收，然后通过组合的方式来完成 GC 的整体职责。而 G1 是第一个同时支持年轻代和老年代垃圾回收的垃圾回收器。在此之后，其他的垃圾回收器也遵循了这样的发展路线。

G1 垃圾回收算法

G1 内存划分

区别于其他采用分代收集算法的垃圾回收器，G1 中的年轻代、老年代是一种逻辑划分，而不再是物理划分，也就是说年轻代和老年代不再是连续的内存地址空间，而是一组 Region 的集合。这里的 Region 是 G1 中最小内存分配单元，你可以通过 -XX:G1HeapRegionSize=n 来设置 Region 的大小，可以设定为 1M、2M、4M、8M、16M、32M。

需要注意的是，JVM 中规定 Region 的大小必须是 2 的整数幂，并且不能超过 32M。如下图所示，当你采用 G1 作为垃圾收集器时，JVM 会将堆内存划分为一个个大小相同的 Region 进行管理。所以合理设置 Region 的大小，是用好 G1 的一个非常重要的因素。

垃圾回收算法

G1 采用的是分代收集和区域（Region）划分相结合的垃圾回收算法。在最小的物理内存单元是 Region 的基础上，依据分代收集算法，G1 将堆内存在逻辑层面划分为 4 个区域，分别是 Eden Space、Survivor Space、Old Generation 以及 Humongous Space。

一个对象的大小如果超过了 Region 容量的一半，就会被直接存放至 Humongous 区域。当对象的大小远超 Region 大小的时候，JVM 会分配连续的 Humongous Region 用来存放这个对象。

image.png

GC 模式

基于上面提到的内存划分和垃圾回收算法，在 G1 中存在三种 GC 模式，分别是 Young GC、Mixed GC 和 Full GC。

image.png

和所有采用分代收集算法的垃圾回收器一样，当 Eden 区的内存空间无法支持新对象的内存分配时，G1 会触发 Young GC。当需要分配对象到 Humongous 区域或者堆内存的空间占比超过 -XX:G1HeapWastePercent 设置的 InitiatingHeapOccupancyPercent 值时，G1 会触发一次 concurrent marking，它的作用就是计算老年代中有多少空间需要被回收，当发现垃圾的占比达到 -XX:G1HeapWastePercent 中所设置的 G1HeapWastePercent 比例时，在下次 Young GC 后会触发一次 Mixed GC。所谓 Mixed GC 是指回收年轻代的 Region 以及一部分老年代中的 Region。在 Mixed GC 过程中，如果发现老年代空间还是不足，此时如果 G1HeapWastePercent 设定过低，可能引发 Full GC。-XX:G1HeapWastePercent 默认是 5，意味着只有 5% 的堆是“浪费”的。如果浪费的堆的百分比大于 G1HeapWastePercent，则运行 Full GC。

Full GC 是在日常生产中需要格外关注的情况，因为它不仅会影响用户体验，更有可能引发雪崩。

预期停顿模型

在以 Region 为最小管理单元以及所采用的 GC 模式的基础上，G1 建立了停顿预测模型，即 Pause Prediction Model 。这也是 G1 非常被人所称道的特性。借助 -XX:MaxGCPauseMillis 参数，你可以设定一个 G1 收集过程目标停顿时间，默认值是 200ms，不过它不是硬性条件，只是期望值。作为一个响应时间优化的 GC 算法，这也是它和 CMS 一个非常大的不同。

此文章为9月Day21学习笔记，内容来源于极客时间《云时代JVM实战 》，强烈推荐该课程