OpenJDK 28 版本即将发布，我认为是时候再次讨论 HotSpot VM 中 OpenJDK 停止世界收集器的有趣变化了。关于 JDK 27 的 GC 子组件已解决/关闭变化的完整列表在这里，包含大约 350 个变化。这个原始计数与上一个版本一致；与之前类似，由于 GC 代码中相当不寻常数量的重构和清理，这些数字可能会有些夸大。一个特别的领域是替换我们表示跨线程共享变量的惯用法，从使用 volatile 和相应的 AtomicAccess 方法到使用 JDK-8367013 中引入的 Atomic<T> 来使其用法更明确。其他值得注意的重构包括 G1 状态机的清理（包括一些非常古老的）和其他代码改进。这些大约占总变化的一半。大约 35% 的变化涉及 bug 修复和一般的正确性及稳健性改进。其余部分则是 HotSpot 的 STW 收集器的新特性或重大修订行为 - 这一部分在本文中将进一步深入探讨 :) 这些变化中混合了 JEP 401: 值对象（预览） 的基础设施工作，例如适应对象迭代器和对值对象的急迫回收。本次发布中影响最大的变化可能是 JEP 523: 使 G1 成为所有环境中的默认垃圾收集器。如果没有在命令行中明确指定任何垃圾收集算法，G1 现在就是默认收集器。没有例外，任何情况下默认不使用 Serial GC（也就是说，除非您的 OpenJDK 发行版中不包含 G1）。我们认为 G1 作为默认收集器非常合适，而根据古怪的环境条件选择其他东西，更像是一种负担而不是优势。在过去几个发布中，吞吐量、内存占用和延迟特征逐步接近 Serial GC，因此我们觉得是时候翻转开关了。如果您观察到显着差异，可以使用 -XX:+UseSerialGC 选项选择 Serial GC 以获取纯、未变的 Serial GC。显然，在某些情况下，对于您的应用程序配置，Serial GC 是更好的选择 - G1 并不是在所有地方都是最好的，但我们认为一定是最好的起点。除了这一变化，还有其他几个变化：G1 不再根据（任意）-XX:MinHeapFreeRatio 和 -XX:MaxHeapFreeRatio 百分比在 Full GC 后调整堆的大小，即，它们的默认值已被设置为不会影响常规、其他启发式大小调整（例如，垃圾收集器的 CPU 使用相对于应用程序的 CPU 使用）。JDK-8238686 将它们的默认值分别设置为 0 和 100%，而不是以前的 40 和 70%。原来的默认值导致这种启发式和其他基于 CPU 使用的启发式相互抵消，导致不必要的 Java 堆大小修改，产生了一旦进行完全堆垃圾收集缩小堆后，其他启发式几乎立即撤销这些变化所导致的性能问题。除此之外，这些标志的功能得以保留。自适应启动的并发标记已得到改善，可以更好地抵御不利条件，这些条件以前会导致不必要的连续并发工作（JDK-8379846，JDK-8381006）。以前，实际上可以回收的庞大对象被弱引用（例如 java.lang.ref.Reference 实例）意外地保持活动状态，已通过 JDK-8378331 和 JDK-8378336 修复。Minor observable changes include that the G1 Cleanup pauses do not update MemoryPoolMXBean.getCollectionUsage() as they do not change the Java heap in JDK-8386332 。JDK-8373894 在之前的垃圾收集中，未能找到足够的空间进行复制的垃圾收集未计入垃圾收集器 CPU 使用中。将它们纳入考虑改善了堆大小决策。Parallel GC 有一些显著的错误修复可能改善性能：自适应晋升阈值决定一个对象可以在年轻代中停留多少次年轻收集。以前，阈值往往只会增加，但很少减少。这意味着这种持续较高的阈值可能留住较旧的对象占据大部分的存活空间，强迫年轻对象在填满时过早晋升。通过 JDK-8380590，阈值也可以下降，更早地晋升长寿命对象并保留可能很快就会死亡的年轻对象。Parallel GC 现在在重复大分配导致数千次 Full GC 的情况下正确地扩展 Java 堆，而当 Java 堆没有增长即使有足够的头部空间时（JDK-8377561）。Serial GC 没有显著的 Serial GC 特定变化 - 除了在某些情况下不再是默认收集器。所有收集器 对所有收集器有一些有趣的变化：TLAB 大小现在更好地处理创建许多短期、轻度分配线程的应用程序。