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

Question

直到Java的8,我们已经看到了并行GC作为默认的垃圾收集,但最新的Java(Java的9)释放想出了G1 GC作为默认的垃圾收集.

为什么Java转移到G1 GC？是否有任何性能提升？

Answer 1

来自JEP 248(JEP - JDK增强提案)

摘要

使G1成为32位和64位服务器配置的默认垃圾收集器.

动机

通常,限制GC暂停时间比最大化吞吐量更重要.对于大多数用户而言,切换到低暂停收集器(例如G1)应该比面向吞吐量的收集器(例如当前默认的并行GC)提供更好的整体体验.

在JDK 8及其更新版本中对G1进行了许多性能改进,并计划对JDK 9进行进一步改进.在JDK 8u40中引入并发类卸载(JEP 156)使G1成为一个功能齐全的垃圾收集器,准备好了默认.

总而言之,这是他们长期努力的事情,而对于Java 9,他们最终决定它已经准备好默认了.

Answer 2

Oleg的回答确实指出了g1gc（有用的标签信息）的引入的动机。

为什么Java迁移到G1 GC？他们的性能有所改善吗？

列出我从java-9引入的最新更改中学到的一些关键改进如下：

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

与在Java 8之前用作默认GC 的Parallel GC相比，避免使用Full GC是主要改进之一。

G1的目标是在不限制堆大小或实时数据量的情况下最小化暂停时间。这是通过同时执行大部分GC工作和部分压缩来实现的。避免执行完整的GC（即世界末日的GC）是G1的主要优势之一。

在此期间，G1的主要功能改进之一是引入了并发类卸载。以前，G1将所有课程都视为实时课程，但在完整GC期间除外。这主要是伴随着永久一代的撤离。

• G1中的字符串重复数据删除

  从使用该应用程序的角度来看，另一个功能是在G1 GC中实现自动和连续的字符串重复数据删除，以避免浪费内存并减少内存占用。该更改与String该类的内部表示形式从UTF-16char数组更改为byte数组以及提议作为紧凑字符串的编码标志字段一起进行。

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