近年来，C#（在.NET世界中并不是唯一的玩家）增加了许多特性来减少GC压力。毫无疑问，所有这些特性都使我们能够构建更好、更高效的应用程序。但是，不管随着时间的推移增加了什么语言和VM（CLR、JVM）特性，高性能和无阻塞的GC是托管应用程序的关键性能因素。
最近在JVM世界里出现了两个新的GC，它们似乎提供了显著的度量。（包括作者）提供了有关这些GC的基准和技术见解。我们可以了解到最大STW（停止世界）间隔“被承诺”不再是10 ms，并且通常平均在1 ms以下振荡，而不管堆大小。还有一些测试表明，新的GC开销得到了很好的平衡，不会对应用程序吞吐量产生负面影响，而同时大大减少了（10倍或更多）STW暂停。
另一方面，关于CLR GC的信息非常少。是否有任何最新的资源可以了解CLR GC如何（4.8、核心3.1、NET 5）与最新的JVM成就相比？我可以找到一些讨论CLR GC与G1的旧来源。但今天的G1不是ZGC/Shenandoah的对手，旧来源也没有显示今天的现实。考虑到没有更新的来源，我们可以得出结论，CLR GC指标自那时以来没有显著改善。但这看起来像是2020年.NET平台的一个真正的问题，因为平均STW约为20-30毫秒，偶尔会跳到300+与JVM上的平均1 ms和最大10 ms（GC制造商声称和测试似乎证实了这一点）的暂停相比，1 ms的暂停看起来真的很糟糕。
我必须说，这让我有点担心，因为有一大堆应用程序中GC暂停非常重要。（例如.NET、JVM、本机...）应该被认为是可行的任务或目的.它看起来像最新的GC的JVM打开了新的领域为Java和其他JVM语言/技术.我们不允许应用程序停止500 ms左右可能性区域，因为GC必须完成其工作，而最大值为~ 10 ms，平均值为~ 1 ms就足够了
今天的真相是什么？CLR GC与最新的JVM GC相比如何？关于CLR上的STW暂停有什么保证吗（看起来JVM正在朝着这个方向发展）？
2条答案
按热度按时间bz4sfanl1#
这是一个很大的主题，但如果我必须总结一下：
我们不允许应用程序停止500 ms左右可能性区域，因为GC必须完成其工作，而最大值为~ 10 ms，平均值为~ 1 ms就足够了
根据我的非代表性经验，在使用. NET时，每次gen 0收集的GC暂停时间可能在5到15 ms之间。如果您的目标是1 ms左右，您可能需要完全禁用GC。我知道一些公司正在.NET中进行高频交易，因此这表明这是可能的。但这只是因为他们有能力在交易时间之外重新启动服务器。如果您需要持续的~1 ms暂停时间，那么.NET还没有做好准备。
5ktev3wc2#
由于固有的设计差异，JVM的最新垃圾收集器很可能会大大优于CLR的垃圾收集器。这背后的主要原因是CLR在默认情况下处理内存的能力稍好一些，而JVM确实受到了一些影响。因此，并没有太大的压力来使CLR中的垃圾收集器快速运行，因为一个简单的设计就足够了，而且做得很好。相比之下，JVM确实需要更好的GC，事实上可能有迄今为止最先进的GC。虽然这可能不会使JVM比CLR快几个数量级，如果您让它们的GC相互竞争，CLR将毫无胜算，尤其是对于像Z和Shenandoah这样的较新JVM GC。