为什么G1是Java9的默认垃圾收集器？

Question

直到Java 8，我们已经看到并行GC作为默认垃圾收集器，但是最近发布的Java (Java9)使用G1 GC作为默认垃圾收集器。

为什么Java已经转移到G1 GC了？性能有什么改善吗？

Answer 1

来自9月248 (JEP - JDK增强方案)

摘要 使G1成为32位和64位服务器配置上的默认垃圾收集器。 动机 限制GC暂停时间通常比最大化吞吐量更重要。对于大多数用户来说，切换到低暂停收集器(如G1 )应该比面向吞吐量的收集器(如目前默认的并行GC )提供更好的总体体验。 JDK 8中的G1及其更新版本进行了许多性能改进，并计划对JDK 9进行进一步改进。在JDK 8u 40中引入并发类卸载(JEP 156)，使G1成为一个功能齐全的垃圾收集器，可以成为默认的垃圾收集器。

总之，这是他们工作了很长时间的事情，对于Java 9，他们最终决定这是默认的。

Answer 2

奥列格的答案确实准确地说明了引入g1gc(有用的标记信息)背后的动机。

为什么要转到G1 GC？他们的性能有改善吗？

为了列出我从爪哇-9中最近引入的更改中学到的几个关键改进，应该是：

• G1 GC:减少对完整GC的需求

与作为默认GC的并行GC相比，避免使用完整GC是Java 8之前的主要改进之一。

G1的目标是在不限制堆大小或活动数据量的情况下最小化暂停时间。这是通过同时执行很大一部分GC工作并进行部分压缩来实现的。避免做完全的GCs (_i.e.，停止世界GCs)是G1的主要好处之一.

在此期间，G1的主要特性改进之一是引入了并发类卸载。以前，G1将所有类视为活动类，但在完整GC期间除外。这主要是伴随着http://openjdk.java.net/jeps/122

• G1中的字符串重复 从消费应用程序的角度来看，另一个特性是在G1 GC中实现自动和连续的字符串删除，以避免浪费内存和减少内存占用。随着String类的内部表示形式从UTF-16 char数组更改为byte数组，再加上建议为http://openjdk.java.net/jeps/254的编码标志字段，该更改也随之带来。

尽管如此，G1的资源使用与并行GC不同，它还指出，当需要最小化资源使用开销时，应该使用G1以外的收集器，并且在此更改之后，必须显式指定备用收集器。