这篇文章是分析了ZGC和Shenandoah的垃圾回收在数TB内存中只有毫秒级的暂停时间，并且与Go语言做了比较， Java新家伙赢得了这场低延迟的比赛。Java在低延迟，快速响应，高性能方面优于Go语言和Redis的延迟。文章很长，只做概要摘录：
衡量GC的重要设计指标：
- 程序吞吐量：您的算法减慢了多少程序？这有时表示为收集与有用工作所花费的CPU时间的百分比。
- GC吞吐量：在指定固定的CPU时间量的情况下，收集器可以清除多少垃圾？
- 堆开销：收集器需要多少额外内存超过理论最小值？如果你的算法在收集时分配临时结构，是否会使你的程序的内存使用非常尖锐？
- 暂停时间：你的收集器会暂停的时间有多长？
- 暂停频率：您的收集器多久停止一次？
- 暂停分布：您通常有非常短暂的暂停但有时会有很长的暂停时间吗？或者你更喜欢停顿有点长但一致？
- 内存分配性能：快速，慢速或不可预测的新内存分配？
- 压缩：即使有足够的可用空间来满足请求，您的收集器是否会报告内存不足（OOM）错误，因为该空间已经分散在堆中的小块中？如果没有，你可能会发现你的程序变慢并最终死亡，即使它实际上有足够的内存来继续。
- 并发：您的收集器使用多核机器的程度如何？
- 缩放：当收集器变大时，收集器的工作情况如何？
- 微调性能：收集器的配置有多复杂，开箱即用并获得最佳性能？
- 预热时间：您的算法是否根据测量的行为进行自我调整，如果是，需要多长时间才能达到最佳状态？
- 内存页释放：您的算法是否会将未使用的内存释放回操作系统？如果是的话，何时？
- 可移植性：您的GC是否在CPU体系结构上工作，提供比x86更弱的内存一致性保证？
- 兼容性：您的收藏家使用哪些语言和编译器？是否可以使用非GC设计的语言运行，比如C ++？它需要编译器修改吗？如果是这样，更改GC算法是否需要重新编译所有程序和依赖项？
使用上面指标比较Shenandoah, ZGC 和其他流行GC!
暂停时间
Java GC工程师是一个相当谦逊的团队，即使他们花了数年时间开发新的收集器，也不会卖力推销他们的工作成功。因此，关于ZGC的规范性陈述声称“不会超过10毫秒暂停”，但如果我们转到幻灯片12上的SPECjbb2015基准测试，我们看到实际上，平均暂停时间约为1毫秒。
Shenandoah的暂停时间同样很短。可以看到GC日志以大约200到400暂停微秒，它甚至可以在有小堆的慢速硬件上运行 - 在运行Web服务器的Raspberry Pi上，暂停时间仍然只有3-8毫秒。这对嵌入式设备来说非常好。
请记住，无论堆大小如何，都会获得这些暂停时间。也就是说，如果需要，您可以在数TB的大小上获得毫秒或更短的暂停。能够自动管理大量堆是一项基本功能，可以改变程序的编写方式：如果您的数据集适合这样的堆，您可能根本不需要编写分布式软件。
将这些延迟与本机手动内存管理所带来的延迟进行比较会很有趣。不幸的是，很难找到有关malloc延迟分布的信息。这篇博文描述了一个Redis负载测试，其中glibc malloc延迟的最坏情况大约为10毫秒。这听起来是非常糟糕的情况，但不幸的是，大多数mallocs的基准使用非常不切实际的测试场景，比如分配和立即释放分配，所以很难得到真实的数据。JVM GC使用SPECjbb进行测试，SPECjbb是实施超市物流应用程序的基准。
程序吞吐量
ZGC的目标是开销不低于15％。这与mallocs报告的最坏情况开销相当。将吞吐量与Go收集器进行比较很困难，因为Go收集器的性能影响取决于您选择的内存开销。但是Go的方法对吞吐量的影响非常严重（这里有电子表格）。Shenandoah的吞吐量开销有点差，但仍然在15％-20％左右。
压实Compact
无论 Shenandoah和ZGC收集器实际上是在程序运行时在内存移动字节，不会暂停运行的程序。这个技巧最初可能看起来不可能，但它实际上是所有现代收集器背后的关键理念（Go除外）。压缩compact有用有三个原因：
- 它消除了堆碎片。清除碎片分配器通常存在于手动管理的应用程序中，但它们以增加的开销为代价减少了碎片，并且永远无法完全消除问题。
- 通过以更好地利用缓存的方式重新组织内存中的数据，它可以使程序更快。
- 它能够以高速度清除大量垃圾，这对于本质上是generational 世代的程序非常有用。
内存分配
使用压缩的一个重要原因是它清除了大的连续内存区域。这反过来意味着分配可以快速完成 - 一旦线程抓住了清空堆区域的一大块，它就可以通过简单地增加单个指针并进行比较来分配内存，即只需要两三条指令，内联到分配站点。
释放内存页
Java在内存使用方面声名狼借的原因之一是，它的大多数垃圾收集器都不会经常将内存释放回操作系统。在服务器端没有问题，但是在台式机，尤其是许多程序竞争RAM的开发人员桌面上，这种行为是反社会的。Shenandoah有一个很好的功能 - 即使应用程序处于空闲状态，它也会主动进行垃圾收集，并稳定地将内存释放回操作系统。这使其成为与IDE等桌面应用程序一起使用的潜在不错选择。JVM使用的默认G1收集器也学习了如何在Java 12中执行此操作。
兼容性
JVM运行许多语言，新的GC不仅可以让Java受益，还可以授益与JavaScript，Python，Ruby，Haskell（通过Eta），Clojure，Scala，Kotlin，R，COBOL。
与Go比较
在我之前关于垃圾收集的2016年的文章中，我观察到Go正在宣传自己，因为它有一个“一刀切”的收集器，它比“企业”替代品更好，并且足以在可预见的未来做好一切。但事实并非如此，所以我批评他们的营销方式。几年后，Go团队发表了这个名为“Getting to Go”的优秀演讲，我将其描述为几乎完全相反 - 这非常诚实。
它告诉我们Go GC的设计是以不寻常的方式设计的，主要是由于谷歌之前未提及的内部工程限制，特别是由于对短期成功的惊人需求。
最初的计划是做一个无障碍的并发复制GC。那是长期计划。读取障碍的开销存在很大的不确定性，因此Go想要避免它们。
但是短期内2014年我们不得不一起行动......我们也需要快速的东西并专注于延迟，但性能影响必须小于编译器提供的加速。所以我们受到限制。
我们还关注编译器速度，即编译器生成的代码......在2015年也迫切需要短期成功。
Go的GC设计有另一个限制 - 在他们的同事已经沉迷于暂停延迟的长尾的环境中。
无论原因如何，Go的不寻常的设计选择显然是由于不同寻常的限制：他们在一家公司经历着对尾部延迟的痴迷，他们的编程时间有限，因为他们同时在Go中重写标准库，而且大多数他们所需要的只是非常快地推动暂停延迟以获得“短期成功”。
Go确实降低了暂停延迟，尽管其他领域的成本很高，他们在工程预算有限的情况下很快就做到了，他们获得了他们所需的短期成功。令人遗憾的是，他们采用了一些奇怪的要求，例如不希望向用户公开微调开关，这导致他们被不同程序的各种各样的需求严重压制。
Go编译器是一个经典的批处理作业。暂停时间对于编译器来说根本不重要，只有总运行时间才有效。但是减少暂停时间的技术都会增加总运行时间，因此这是一个问题。用于批处理作业的良好GC算法类似于JVM的并行GC。
他们尝试了一个“面向请求的收集器”，它可以更好地扩展到某些重要的应用程序：
正如你所看到的那样，如果你有ROC而不是很多共享，事情实际上可以很好地扩展。如果你没有ROC，那就差不多了。
但是......它减慢了他们的编译器：
那时我们对编译器有很多担心，我们无法放慢编译器的速度。不幸的是，编译器正是ROC没有做好的程序。我们看到30％，40％，50％和更多的减速，这是不可接受的。Go对其编译器的速度感到自豪。
GC设计很难！Go的人可能已经重走了JVM路线，让用户根据他们是否更关心延迟或吞吐量两种中一个而选择GC算法。
所以他们放弃并尝试了一种新的方法 - 一个普通的世代垃圾收集器。
因此，他们在2018年时的建议是：等待内存价格下降，并要求Go用户给Go应用程序大量的堆内存，以减少当前算法需要完成的GC工作量。
如果我们将这个故事与JVM世界中的等同物进行比较，我们可以看到不同的东西。在SPECjbb 2015基准测试（模拟仓库管理数据库应用程序）中，ZGC强制实际上不会减慢应用程序的速度，但会显着改善延迟：
暂停时间几乎总是毫秒或更短，但吞吐量不会受到严重损害。
同时有三个标准调整标志选项 - 一个用于选择ZGC而不是另一个算法，一个用于设置最大堆大小，一个通常可以单独保留，因为它会自动调整，但会设置收集器获得的CPU时间。通过利用Linux内核的大页面功能，可以使用一些更加模糊的内容来进一步提高性能。
总的来说，在我看来，Java家伙正在赢得低延迟游戏的胜利。