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
閱讀更多 木子莫 的文章
