一尘不染

为什么Go可以将GC暂停降低到1ms以下,而JVM却没有呢?

go

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

今天,我向垃圾收集器提交了更改,这些更改使典型的最坏情况下的世界停止时间小于100微秒。对于具有许多活动goroutine的应用程序,这应该尤其可以改善暂停时间,而以前可能会大大增加暂停时间。

如果JVM用户长期苦苦挣扎,GC停顿就很高。

有哪些(架构上的)约束条件可以阻止JVM将GC暂停降低到Go级别,但不会影响Go?


阅读 520

收藏
2020-07-02

共1个答案

一尘不染

有哪些(体系结构上的)约束条件可以阻止JVM将GC暂停降低到golang级别

没有。

如果JVM用户长期苦苦挣扎,GC停顿就很高。

稍作谷歌搜索就可以看到类似的解决方案也适用于Java

  • Azul提供不间断的收集器,甚至可以扩展到100GB +
  • 红帽正在协助雪兰到了OpenJDK和Oracle ZGC
  • IBM提供节拍器,也旨在提供微秒的暂停时间
  • 其他各种实时JVM

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

Go的收集器是非世代的,非紧凑的,并且需要写障碍,这会导致较低的吞吐量/更多的CPU收集开销,更高的内存占用量(碎片)以及对缓存对象的缓存效率较低的放置堆(非紧凑型内存布局)。

2020-07-02