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
评论