垃圾回收器的新发展

深藏阁楼爱情的钟 2022-08-29 09:39 132阅读 0赞

# 一 点睛 #

## 1 G1 GC ##

GC 仍然处于飞速发展之中，目前的默认选项 G1 GC 在不断的进行改进，很多我们原来认为的缺点，例如串行的 Full GC、Card Table 扫描的低效等，都已经被大幅改进，例如，JDK10 以后，Full GC 已经是并行运行，在很多场景下，其表现还略优于 Parallel GC 的并行 Full GC 实现。

## 2 Serial GC ##

虽然比较古老，但是简单的设计和实现未必就是过时的，它本身的开销，不管是 GC 相关数据结构的开销，还是线程的开销，都是非常小的，所以随着云计算的兴起，在 Serverless 等新的应用场景下，Serial GC 找到了新的舞台。

## 3 CMS GC ##

比较不幸的是 CMS GC，因为其算法的理论缺陷等原因，虽然现在还有非常大的用户群体，但在 JDK9 中已经被标记为废弃，并在 JDK14 版本中移除。

## 4 JDK 11 出现 Epsilon ##

A No-Op GarbageCollector（Epsilon垃圾回收器，"No-Op（无操作）"回收器）

[http://openjdk.java.net/jeps/318][http_openjdk.java.net_jeps_318]

## 5 JDK11 出现 ZGC ##

A Scalable Low-Latency Garbage Collector（Experimental）（ZGC：可伸缩的低延迟垃圾回收器，处于实验性阶段）

## 6 JDK12 出现 Shenandoah ##

现在 G1 回收器已成为默认回收器好几年了。我们还看到了引入了两个新的收集器：ZGC（JDK11出现）和 Shenandoah（Open JDK12）

> 主打特点：低停顿时间

# 二 Open JDK12 的 Shenandoash GC #

Open JDK12 的 shenandoash GC：低停顿时间的 GC（实验性）

Shenandoah：无疑是众多 GC 中最孤独的一个。是第一款不由 oracle 公司团队领导开发的 Hotspot 垃圾收集器。不可避免的受到官方的排挤。比如号称 openJDK 和 OracleJDk 没有区别的 Oracle 公司仍拒绝在 oracleJDK12 中支持 Shenandoah。

Shenandoah 垃圾回收器最初由 RedHat 进行的一项垃圾收集器研究项目Pauseless GC的实现，旨在针对 JVM 上的内存回收实现低停顿的需求。在2014年贡献给 OpenJDK。

Red Hat研发 Shenandoah 团队对外宣称，Shenandoah 垃圾回收器的暂停时间与堆大小无关，这意味着无论将堆设置为 200MB 还是 200GB，99.9% 的目标都可以把垃圾收集的停顿时间限制在十毫秒以内。不过实际使用性能将取决于实际工作堆的大小和工作负载。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70][]

这是 RedHat 在 2016 年发表的论文数据，测试内容是使用 ES 对 200GB 的维基百科数据进行索引。从结果看：

> 停顿时间比其他几款收集器确实有了质的飞跃，但也未实现最大停顿时间控制在十毫秒以内的目标。
> 
> 而吞吐量方面出现了明显的下降，总运行时间是所有测试收集器里最长的。

小结

*  Shenandoah GC 的弱项：高运行负担下的吞吐量下降。
 *  Shenandoah GC 的强项：低延迟时间。

# 三 革命性的ZGC #

ZGC 与 shenandoah 目标高度相似，在尽可能对吞吐量影响不大的前提下，实现在任意堆内存大小下都可以把垃圾收集的停颇时间限制在十毫秒以内的低延迟。

《深入理解Java虚拟机》一书中这样定义ZGC：ZGC收集器是一款基于 Region 内存布局的，（暂时）不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-压缩算法的，以低延迟为首要目标的一款垃圾收集器。

ZGC 的工作过程可以分为4个阶段：并发标记 - 并发预备重分配 - 并发重分配 - 并发重映射 等。

ZGC 几乎在所有地方并发执行的，除了初始标记的是 STW 的。所以停顿时间几乎就耗费在初始标记上，这部分的实际时间是非常少的。

吞吐量对比

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70 1][]

停顿时间对比

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70 2][]

虽然 ZGC 还在试验状态，没有完成所有特性，但此时性能已经相当亮眼，用“令人震惊、革命性”来形容，不为过。

未来将在服务端、大内存、低延迟应用的首选垃圾收集器。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70 3][]

JDK14之前，ZGC 仅 Linux 才支持。

JDK14新特性如下：

尽管许多使用 ZGC 的用户都使用类 Linux 的环境，但在 Windows 和 Macos 上，人们也需要 ZGC 进行开发部署和测试。许多桌面应用也可以从 ZGC 中受益。因此，ZGC 特性被移植到了 Windows 和 Macos 上。

现在 Mac 或 Windows 上也能使用 ZGC 了，示例如下：

> \-XX:+UnlockExperimentalVMOptions-XX：+UseZGC

# 四 AliGC #

AliGC 是阿里巴巴 JVM 团队基于 G1 算法，面向大堆（LargeHeap）应用场景。指定场景下的对比：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70 4][]

当然，其它厂商也提供了各种别具一格的 GC 实现，例如比较有名的低延迟GC Zing。

[http_openjdk.java.net_jeps_318]: http://openjdk.java.net/jeps/318
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70]: /images/20220829/008a228161a745909e2ed6bd9af16ab6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70 1]: /images/20220829/bcabe8dcc9d84d319ae5bba731f1e87a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70 2]: /images/20220829/c0aa3d4cf87546df865ca33bfda92e56.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70 3]: /images/20220829/b3be11222f1b4e46906e988279298bca.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5ncWl1bWluZw_size_16_color_FFFFFF_t_70 4]: /images/20220829/ae33239902a04c839e06c1b58b1ed070.png