你用的是什么垃圾收集器？

我们的研究实验室正全速运转。用recent injection of capital，我们只能保证我们不断创新的步伐只会加快。我们进行的部分研究与气相色谱优化有关。在处理这个有趣领域的问题时，我们想分享一些对气相色谱算法使用的见解。

为此，我们进行了一项研究particular GC algorithm正在被使用。结果有些令人惊讶。让我从数据的背景开始——我们可以访问代表2670个不同环境的84，936个会话的数据，用于研究。13%的环境明确指定了垃圾收集算法。其余的由JVM来决定。因此，在11，062个具有显式垃圾收集算法的会话中，我们能够区分六种不同的垃圾收集算法:

在理解GC算法使用的细节之前，我们应该停下来一分钟，试着理解为什么87%的运行没有出现在上面的饼图中。我们认为，这是两个不同潜在原因的症状

• 第一个也是很好的理由是JVM已经变得非常擅长选择合理的缺省值，以至于开发人员不再需要在幕后挖掘。如果您的应用程序吞吐量和延迟足够了，那为什么还要费心呢？
• 缺乏垃圾收集算法的第二个可能的原因表明，应用程序性能并不是团队的首要任务。如同our case study from last year demonstrated–吞吐量和延迟方面的显著改善只需一次配置调整。

因此，我们有近83，000个运行默认垃圾收集选择的JVM。但是什么是默认呢？答案既简单又复杂。如果您被认为是在客户端JVM上运行，那么JVM应用的缺省值将是串行GC(-XX:+useseriagc)。在服务器级机器上，缺省值是并行GC (-XX:+UseParallelGC)。您是在服务器上运行还是在客户机上运行，可以根据以下决策表来确定:

但是让我们回到在配置中明确指定了垃圾收集算法的13%。它从好的老串行模式开始，毫不奇怪，它的用户基数很小，从上图中几乎看不到。事实上，只有31个环境确信这是最好的垃圾收集算法，并明确指出了这一点。考虑到当今大多数平台都运行在多核机器上，你不应该感到惊讶——当你有几个内核可供使用时，几乎总是建议从串行模式切换。

配置的其余部分可分为三组:并行、并发和G1。赢家很明显——并发标记和扫描算法加起来代表了超过三分之二的样本。但是让我们更深入地看看结果。

并行模式和并行模式大致相同，分别有1，422和1，193个样本。这不足为奇——如果你已经决定并行模式适合你的年轻一代，那么同样的算法在老一代中通常也表现良好。并行模式的另一个有趣的方面是——从上面可以看出，并行模式在最常见的平台上是默认的，因此缺乏明确的规范并不意味着它不如替代模式受欢迎。

使用内容管理系统，我们的期望是不同的。也就是说，与6655种配置的经典内容管理系统相比，增量模式仅在935种情况下开启。提醒您——在并发阶段，垃圾收集器线程使用一个或多个处理器。增量模式用于减少长并发阶段的影响，方法是定期停止并发阶段，将处理器交还给应用程序。这将缩短暂停时间，尤其是在处理器数量较少的机器上。这些环境是否都有数百万个内核，或者负责配置的人只是不知道增量模式的好处，目前还不清楚。

但我们最大的惊讶与G1的采纳率有关。826个环境以G1作为垃圾收集算法运行。根据我们的经验，不管您是追求吞吐量还是延迟，G1的表现往往比CMS差。也许我们已经接触到的测试用例的选择很差，但是目前我们认为G1需要更多的时间来兑现它的承诺。所以如果你是一个快乐的G1用户，也许你可以和我们分享你的经验？

希望我们能给你一些启发。我只能保证会有更多关于这个话题的报道，所以请继续关注并订阅RSS源吧！