New Relic发布了一份新的JVM报告，该报告基于其全球客户在生产环境中运行的JVM报告的数据的分析。与其他自我报告调查不同，这里生成的数据来自正在生产环境中运行的JVM。正如所料，结果数据集来自New Relic的客户，但它描绘了在生产中的使用情况，而不是开发人员在工作和测试中的使用情况。

特别得，该报告重点指出，在生产环境中运行的大多数JVM都使用的是Java的LTS版本；只有11%多一点运行在Java 11上。大多数JVM（超过85%）运行在Java 8上，Java 7紧随其后，只有几个百分点。非LTS版本仅占所报告的运行机器的1%多一点。此外，报告还特别指出，JVM用户在生产环境中的升级速度通常很慢；在7之前的Java版本上运行的JVM比在9或10（都已EOL）或12和13（都已EOL或即将EOL）上运行的版本还多。该报告还强调，许多JVM运行在过时的Java 8版本上，其中一些存在已知的安全漏洞。

其数据另一个有趣的方面是，尽管Oracle仍然是JVM的主要供应商（略低于75%），但可以看到，许多其他供应商开始致力于提供运行时。Adopt OpenJDK是排名第二高的提供商，占7%，紧随其后的是Iced Tea，占5%多一点（GNU发行版使用），Azul、IBM和Amazon各占不到3%的份额，还有许多其他一长串的提供商。

报告还着重指出了生产环境中使用的垃圾收集器；Parallel仍然是垃圾收集器的首选，占JVM的57%以上，G1的占比略低于25%，CMS的占比则略高于17%。在一定程度上，这种差异可以用JVM的版本来解释，因为G1收集器在Java 8中成为默认垃圾收集器，自发布以来逐渐成熟。但却出现了这样一种结果——在Java 8上超过14%的JVM使用了CMS， G1是13%——看看随Java版本出现的这种变化是一个有趣的统计。也许并不奇怪，结果中没有看到Shenandoah或ZGC在生产环境中的大量应用，只有一小部分配置了这两者中的一种。

最后，JVM的内存配置显示了各种各样的内存大小，从256Mb到16384Mb。奇怪的是，我们看到的JVM中约有2.5%使用了最大大小为819Mb的内存，这很可能是8192Mb的复制和粘贴错误，如这里所示。超过三分之一的JVM报告使用相同的-Xmx和-Xms标识运行；建议是，虽然这对于较旧的JVM是必要的，但是当初始大小和最大大小允许不同时，比较新的垃圾收集器启发式方法可能会工作得更好。

InfoQ已询问是否可以获得数据的匿名拷贝以供进一步分析，如果数据放出的话，我们会更新这篇文章。

原文链接：

New Relic – the State of Java Report

创作场景

Java 状态报告：Java 8 占主导，Java 11 不算多