垃圾收集算法,垃圾收集器_您正在使用什么垃圾收集器？

垃圾收集算法,垃圾收集器

我们的研究实验室正全速前进。 随着最近的资本注入 ，我们只能保证我们不断创新的步伐只会加快。 我们进行的部分研究与GC优化有关。 在处理这个有趣的领域中的问题时，我们认为可以分享一些有关GC算法使用的见解。

为此，我们对使用特定GC算法的频率进行了研究。 结果有些令人惊讶。 让我从数据的背景开始–我们可以访问来自84,936个会话的数据，这些会话代表2670种不同的环境用于研究。 13％的环境明确指定了GC算法。 其余的决定权交给了JVM。 因此，在使用显式GC算法的11,062会话中，我们能够区分出六种不同的GC算法：

在了解有关GC算法用法的详细信息之前，我们应该停一分钟，然后尝试理解为什么上面的饼图中缺少87％的运行。 我们认为，这是两个不同根本原因的征兆

• 首先也是有充分理由的是– JVM在选择合理的默认值方面已经表现出色，以至于开发人员不再需要深入研究。 如果您的应用程序吞吐量和延迟足够，那么–为什么要打扰？
• 缺少GC算法的第二个可能原因表明，应用程序性能并不是团队的首要任务。 正如我们去年的案例研究所表明的那样，仅需调整一项配置即可显着提高吞吐量和延迟。

因此，我们有将近83,000个使用默认GC选择运行的JVM。 但是默认值是什么？ 答案既简单又复杂。 如果认为您正在客户端JVM上运行，则JVM所应用的默认值为串行GC（-XX：+ UseSerialGC）。 在服务器级计算机上，默认值为并行GC（-XX：+ UseParallelGC）。 可以基于以下决策表确定是在服务器还是客户端类计算机上运行：

建筑	CPU /内存	操作系统	默认
i586	任何	微软视窗	客户
AMD64	任何	任何	服务器
64位SPARC	任何	的Solaris	服务器
32位SPARC	2个以上内核和> 2GB RAM	的Solaris	服务器
32位SPARC	1核或<2GB RAM	的Solaris	客户
i568	2个以上内核和> 2GB RAM	Linux或Solaris	服务器
i568	1核或<2GB RAM	Linux或Solaris	客户

但是，让我们回到在配置中已明确指定GC算法的13％的人。 它以良好的旧串行模式开始，毫无疑问，它的用户群如此之小，以至于在上图中几乎看不到它。 实际上，只有31个环境确定这是最佳的GC算法，并且已明确指定了该算法。 考虑到当今大多数平台都在多核计算机上运行，​​您应该不会感到惊讶–当您拥有多个核时，几乎总是建议从串行模式切换。

GC	计数
序列号	31
平行	1,422
平行旧	1,193
ConcMarkSweep	6,655
CMSIncrementalMode	935
G1	826

其余配置可以分为三组-并行，并发和G1。 赢家是显而易见的-并发标记和扫描算法相结合构成了样本的三分之二以上。 但是，让我们更深入地研究结果。

Parallel和ParallelOld模式大致在同一邻域中，具有1,422和1,193个样本。 不足为奇–如果您确定并行模式适合您的年轻一代，那么对于老一代而言，相同的算法通常也表现良好。 并行模式中另一个有趣的方面是–从上面可以看出，并行模式是大多数常见平台上的默认模式，因此缺乏明确的规范并不意味着它不比其他模式流行。

对于CMS，我们的期望有所不同。 即–与具有6556种配置的传统CMS相比，增量模式仅在935次打开。 提醒您-在并发阶段，垃圾收集器线程正在使用一个或多个处理器。 增量模式用于通过定期停止并发阶段以使处理器退还给应用程序来减少长时间的并发阶段的影响。 这样可以缩短暂停时间，尤其是在处理器数量少的机器上。 目前尚不清楚环境是全部拥有海量核心，还是负责配置的人员都不知道增量模式的好处。

但是我们最大的惊喜与G1的采用率有关。 G1作为垃圾收集算法正在运行826个环境。 根据我们的经验，无论您是追求吞吐量还是等待时间，G1的表现都比CMS差。 也许我们可以访问的测试用例的选择不多，但是目前我们认为G1需要更多的时间来实际兑现其承诺。 因此，如果您是快乐的G1用户，也许可以与我们分享您的经验？

参考： 您正在使用什么垃圾收集器？ 由我们的JCG合作伙伴 Nikita Salnikov Tarnovski在Plumbr Blog博客上获得。

翻译自: https://www.javacodegeeks.com/2013/11/what-garbage-collector-are-you-using.html

垃圾收集算法,垃圾收集器