在 Java 8 之前，我们将 Parallel GC 视为默认垃圾收集器，但最近发布的 Java (Java 9) 提出了 G1 GC 作为默认垃圾收集器。
为什么 Java 迁移到 G1 GC ？ 有没有性能提升？
【问题讨论】：
标签： java garbage-collection java-9 g1gc
来自JEP 248（JEP - JDK 增强提案）
总结
将 G1 设为 32 位和 64 位服务器配置上的默认垃圾收集器。
动机
一般来说，限制 GC 暂停时间比最大化吞吐量更重要。对于大多数用户而言，切换到 G1 等低暂停收集器应该会比当前默认的 Parallel GC 等面向吞吐量的收集器提供更好的整体体验。
在 JDK 8 及其更新版本中对 G1 进行了许多性能改进，并计划对 JDK 9 进行进一步改进。在 JDK 8u40 中引入并发类卸载 (JEP 156) 使 G1 成为功能齐全的垃圾收集器，准备就绪成为默认值。
总而言之，这是他们长期致力于的事情，对于 Java 9，他们最终决定将其作为默认设置。
【讨论】：
Oleg 的回答确实准确地说明了引入g1gc（有用的标签信息）背后的动机。
为什么 Java 迁移到 G1 GC？他们的性能有什么提升吗？
列出我从java-9 中引入的最新更改中学到的几个关键改进是：
与在 Java 8 之前用作默认 GC 的 Parallel GC 相比，避免 Full GC 是主要改进之一。
G1 的目标是在不限制 堆大小或实时数据量。这是通过做一个 GC 的大部分同时工作并且也在做部分工作 压实。避免执行完整的 GC（_i.e.，stop-the-world GC）是其中之一 G1 的主要好处。
在此期间，G1 的主要功能改进之一是引入了并发类卸载。以前 G1 将所有课程视为实时课程，除了在完整 GC 期间。这主要伴随着removal of the permanent generation.
从消费应用的角度来看，另一个特性是
在 G1 GC 中实现自动和连续的字符串重复数据删除，以避免浪费内存并减少内存占用。这一变化伴随着String 类的内部表示从UTF-16 字符数组到byte 数组以及提议为compact strings. 的编码标志字段的变化而带来。
尽管如此，G1 的资源使用与 Parallel GC 不同，并且它还指出当资源使用开销需要最小化时，应该使用 G1 以外的收集器，并且在此更改之后必须明确指定备用收集器。
【讨论】：