通過調查數以百萬計的JVM虛擬機器發現當前Java使用情況 - Ben Evans

banq發表於2020-03-14
JVM虛擬機Java

每天，數千萬的Java虛擬機器（JVM）與New Relic共享它們的資料。為了建立此報告，我們對資料進行了匿名處理並對其進行了粗粒度處理，以給出我們所看到的Java生態系統的大致概述。我們還避免使用任何可能有助於攻擊者和其他惡意方（否則會破壞JVM資料使用者）的詳細資訊。

這些觀察的目標是提供有關當今Java生態系統狀態的一些新上下文和見解。說了這麼多，我們看了以下幾類：

  • 生產中使用的Java版本。
  • 最受歡迎的供應商。
  • 最常用的垃圾收集演算法
  • 最常見的堆大小配置。

Java 8仍然是標準 

14 Total:    0.00
13 Total:    0.32
12 Total:    0.17
11 Total:    11.11
10:    0.48
9 :   0.18
8 Current:    42.02
8 Lagging:    38.63
8 Vulnerable:    3.83
7:    2.54
pre-7:    0.73
Non-LTS:    1.14

注意：我們將Java 8結果分為三個部分：

  • Current
    ：最近更新，並且不受任何主要的近期CVE的影響。 
  • Lagging
    ：與Java版本的使用時間相關的潛在重大風險。 
  • Vulnerable
    ：執行這些版本的團隊可能會引起嚴重關注。

Java 11（一個長期支援版本）正在逐漸普及，但是與Java 8（也包括LTS）相比，市場似乎仍然猶豫不決。值得注意的是，缺乏採用非LTS版本的情況-Java 7的使用率（2.54％）仍然是所有Java 8後非LTS版本的總和（1.14％）的兩倍多。

非Oracle供應商的興起

甲骨文現在僅佔Java市場的75％。由社群主導的AdoptOpenJDK是第二受歡迎的供應商。我們的歷史趨勢資料（我們尚未釋出，因為它的樣本量比主要資料集要小得多）表明AdoptOpenJDK的受歡迎程度逐月上升。

特別要注意的是，在向New Relic報告的AdoptOpenJDK VM群體中，幾乎有三分之一（33.19％）是Java11。與一般人群相比，這代表了AdoptOpenJDK使用者中Java 11的使用率高得多。

注意：為了全面披露，New Relic是AdoptOpenJDK專案的贊助商，並正在為該專案貢獻工程時間。

“垃圾收集”演算法如何發揮作用

Parallel    57.77
G1    24.99
CMS    17.20
ZGC    0.04
Shenandoah    <0.01

大致而言，這些選擇反映了不同Java版本上使用的預設收集器。但是，當我們使用JVM版本時，會出現一些有趣的結果：

  • 在Java 8上，CMS比G1更為流行（14.56％對12.59％）。
  • 在Java 11上，CMS比Parallel更為流行（3.96％對0.20％）。
  • 在Java 11上，CMS的流行度是ZGC的35倍以上。

Xms/Xmx配置

Xms：2048MB Xmx：2048MB 佔比8.84
Xms：512MB Xmx：512MB 佔比8.74
Xms：1024MB Xmx：1024MB 佔比5.76
Xms：4096MB Xmx：4096MB 佔比2.83
...

Xpin和Xmx具有相同值的組合是一個重大驚喜。我們的資料顯示，仍有33.48％的JVM以此組合執行。在自適應大小調整演算法的早期版本中，使用這種組合執行可能會有一些優勢，但對於現代工作負載，幾乎總是適得其反。如果設定此組合，則JVM將受其如何調整堆大小和各種的約束，從而使其對流量行為或請求速率的突然變化的響應能力降低。

如果執行時中存在此組合，則可能需要執行一些測試，以檢視是否可以刪除它以提高垃圾回收效能。

一些隨機但有趣的東西

最後，我們觀察了以下五個有趣的統計資料：

  1. Java 8 JVM的7.35％使用不推薦使用的標誌（尤其是MaxPermSize）執行。
  2. 所有JVM中有6.78％在啟用實驗性標誌的情況下執行。
  3. 8.07％的JVM具有重複的標誌，這些標誌在啟動字串中出現多次。
  4. 2.54％的JVM具有“不匹配的標誌”，表示矛盾的事物；例如，標誌指定並行GC和G1GC。
  5. 2.59％的JVM設定最大堆大小為819MB。這幾乎可以肯定是8192MB（即8GB）的錯字。仔細檢查您的配置-貼上貼上配置很危險。

相關文章