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 是必要的，但是当初始大小和最大大小允许不同时，比较新的垃圾收集器启发式方法可能会工作得更好。
