go - 为什么 Go 可以将 GC 暂停时间降低到 1 毫秒以下，而 JVM 却没有？

Question

那就是:https://groups.google.com/forum/?fromgroups#!topic/golang-dev/Ab1sFeoZg_8 :

Today I submitted changes to the garbage collector that make typical worst-case stop-the-world times less than 100 microseconds. This should particularly improve pauses for applications with many active goroutines, which could previously inflate pause times significantly.

高 GC 停顿是 JVM 用户长期困扰的问题之一。

阻止 JVM 将 GC 暂停降低到 Go 级别但不影响 Go 的(架构？)约束是什么？

Answer 1

2021 年更新:在 OpenJDK 16 中，ZGC 现在拥有 max pause time of <1ms and average pause times 50µs

与 Go 的收集器不同，它在执行压缩的同时实现了这些目标。

更新:在 OpenJDK 17 中，Shenandoah 利用了 ZGC 和 achieves similar results 引入的相同技术.

---

What are the (architectural?) constraints which prevent JVM from lowering GC pauses to golang levels

没有任何基本的，因为低暂停 GC 已经存在了一段时间(见下文)。因此，这可能更多是来自历史经验或开箱即用配置的印象差异，而不是可能的。

High GC pauses are one if the things JVM users struggle with for a long time.

谷歌搜索表明类似的解决方案也适用于 java

• Azul 提供 pauseless collector甚至可以扩展到 100GB+
• Redhat 正在贡献 shenandoah openjdk 和 oracle zgc .
• IBM 提供 metronome ，同样针对微秒级的暂停时间
• 各种其他实时 JVM

与 Go 不同，openjdk 中的其他收集器是压缩代收集器。这是为了避免碎片问题，并通过启用凹凸指针分配和减少在 GC 中花费的 CPU 时间，在具有大堆的服务器级机器上提供更高的吞吐量。并且至少在良好的条件下，CMS 可以实现个位数毫秒的暂停，尽管它与移动的年轻代收集器配对。

Go 的收集器是非分代的、非压缩的并且需要写屏障(参见 other SO question)，这会导致收集的吞吐量降低/CPU 开销增加、内存占用增加(由于碎片化和需要更多的空间)和在堆上放置对象的缓存效率较低(非紧凑内存布局)。

因此，GoGC 主要针对暂停时间进行了优化，同时保持相对简单(按照 GC 标准)，但牺牲了其他几个性能和可​​扩展性目标。 JVM GC 做出了不同的权衡。较旧的通常关注吞吐量。较新的版本以更高的复杂性为代价实现了较短的暂停时间和其他几个目标。