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

Question

直到Java 8，我们已经看到 Parallel 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中引入的最新更改中学到的一些重要改进：

• The G1 GC: Reduce need for full GCs

与用作默认GC的 Parallel GC 相比，在Java 8之前，避免使用完整GC是一项重大改进。

  

G1的目标是在不限制的情况下最小化暂停时间   堆大小或实时数据量。这是通过做一个   大部分GC同时工作，也做部分工作   压实。避免做完整的GC（_i.e。，stop-the-world GCs）就是其中之一   G1的主要好处。

在此期间G1的一个主要功能改进是引入了并发类卸载。除了在完整的GC期间，之前G1将所有课程视为现场直播。这主要伴随着removal of the permanent generation.

• String Deduplication in G1

  消费应用程序的另一个特点是 在G1 GC中实现自动和连续的字符串重复数据删除，以避免浪费内存并减少内存占用。更改随着String类的内部表示从UTF-16 char数组更改为byte数组以及建议为compact strings. <的encoding-flag字段而带来/ p>

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