什么时候不应该使用G1GC垃圾收集器？

Question

我研究了可用于 JVM 的各种垃圾收集器之间的差异。这是解释它们之间主要区别的答案：/sf/answers/3823388691/

对于 G1GC 来说：

它是低暂停/服务器风格的GC，主要用于大堆（> 4Gb）。

我们有一台总内存为 4 GB 的机器，分配给 JVM 的堆大小为 1 GB。我想了解这是否会给我们带来任何问题，或者 G1GC 是否能正常工作。

Answer 1

以下总结基于：

从 Java 14 开始，旧的 CMS 收集器已被删除。

请注意，如果您指定暂停时间和/或吞吐量目标，则可以将 GC 的选择和调整留给 JVM。当您不明白自己在做什么时，这可能比手动选择和调整 GC 的风险要小。

这里描述了这种“基于行为的调整”方法及其优点。

你问：

我们有一台总内存为 4 GB 的机器，分配给 JVM 的堆大小为 1 GB。我想了解这是否会给我们带来任何问题，或者 G1GC 是否能正常工作。

我们无法告诉您这是否会成功。这取决于应用程序行为的各个方面以及您的期望。例如，如果您的应用程序遇到哪些“问题”，您会担心这些问题。我建议首先尝试“基于行为的调整”，看看它会给你带来什么。

最后，设置对于应用程序来说太小的最大堆大小不会有好结果......无论您选择什么 GC。

我完全同意，拥有足够的内存比算法或任何其他调整选项更重要。事实上，如果有足够的内存，GC 所占的 CPU 时间可能会非常低，以至于任何调整都可能毫无意义。这就是为什么我建议使用 Java 9 或更高版本，因为“紧凑字符串”可以显着减少内存占用。然后，尝试打开字符串重复数据删除的 G1GC，如果这可以为您节省另一块内存，那么它也会对性能有所帮助。因此，根据应用程序的不同，这甚至可能比吞吐量收集器（JDK 18 之前的版本）产生更好的吞吐量。 (3认同)
请注意，如果您想要字符串重复数据删除，则串行 GC 不是一个选项（JDK 18 之前）。ZGC 也一样。 (2认同)
还有其他一些事情。就像这样一个事实：如果您有大型的短期对象，最终成为“巨大的对象”，那么 G1GC 可能会令人不快……因为它们会自动获得保有。 (2认同)
看我回答的最后一句。听起来您可能**需要**更大的堆。 (2认同)