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

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《为什么 Go 可以将 GC 暂停时间降低到 1 毫秒以下，而 JVM 却没有？》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

问题内容

所以就是这样：[https://groups.google.com/forum/?fromgroups#!topic/golang- dev/Ab1sFeoZg_8](https://groups.google.com/forum/?fromgroups#!topic/golang- dev/Ab1sFeoZg_8)：

今天我向垃圾收集器提交了更改，使典型的最坏情况停止世界时间少于 100 微秒。这应该特别改善具有许多活动 goroutine 的应用程序的暂停，这可能会显着延长暂停时间。

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

有哪些（架构？）约束阻止 JVM 将 GC 暂停降低到 Go 级别，但不影响 Go？

正确答案

2021 年更新 ：使用 OpenJDK 16，ZGC 现在的最大暂停时间为

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

更新 ：在 OpenJDK 17 中，Shenandoah 利用了 ZGC 引入的相同技术并[获得了类似的结果](https://developers.redhat.com/articles/2021/09/16/shenandoah- openjdk-17-sub-millisecond-gc-pauses)。

阻止 JVM 将 GC 暂停降低到 golang 级别的（架构？）约束是什么

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

如果 JVM 用户很长时间都在努力解决问题，那么高 GC 暂停就是其中之一。

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

• Azul 提供了一个无停顿收集器，甚至可以扩展到 100GB+
• Redhat 正在为 openjdk 和 oracle zgc贡献shenandoah。
• IBM 提供节拍器，同样针对微秒暂停时间
• 各种其他实时 JVM

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

Go 的收集器是非分代的、非压缩的，并且需要写屏障（请参阅 this [other SO question](https://stackoverflow.com/questions/7823725/what-kind-of-garbage- collection-does-go-use)），这会导致吞吐量降低/收集的 CPU 开销增加、内存占用量增加（由于碎片和需要更多空间）和更少的缓存 -在堆上有效放置对象（非紧凑内存布局）。

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

今天带大家了解了golang的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~