Categories
程式開發

Java狀態報告:Java 8占主導,Java 11不算多


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版本上,其中一些存在已知的安全漏洞。

Java狀態報告:Java 8占主導,Java 11不算多 1

其數據另一個有趣的方面是,儘管Oracle仍然是JVM的主要供應商(略低於75%),但可以看到,許多其他供應商開始致力於提供運行時。 Adopt OpenJDK是排名第二高的提供商,佔7%,緊隨其後的是Iced Tea,佔5%多一點(GNU發行版使用),Azul、IBM和Amazon各佔不到3%的份額,還有許多其他一長串的提供商。

Java狀態報告:Java 8占主導,Java 11不算多 2

報告還著重指出了生產環境中使用的垃圾收集器;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