通过调查数以百万计的JVM虚拟机发现当前Java使用情况 - Ben Evans


每天，数千万的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）的错字。仔细检查您的配置-粘贴粘贴配置很危险。