Java 8被抛弃，甲骨文份额萎缩超一半，2022年Java生态报告出炉

【CSDN 编者按】Java 11应用占比超过Java 8，那些高喊Java 8“ YYDS”的人还在继续坚持吗？

近日，知名科技公司New Relic（总部位于美国旧金山的SaaS服务提供商）发布了《2022年Java生态系统状况报告》，旨在揭露当下Java生态系统现状。

报告称，虽然现代规模庞大的软件业中不乏可供选择的编程语言，但Java还是凭借它独立于平台、提供成千上万可支持的库等优点，广受软件开发人员的欢迎。所以，几乎每一个主要的行业和经济部门都可见Java的身影。

2020年3月，New Relic基于数百万个提供性能数据应用程序中收集到的数据，发布了首个《Java生态系统状况报告》。而随着自Java 11以来首个长期支持（LTS）版本——Java 17的发布，以前所收集到的数据都要重新审视。所以，根据最新收集的数据，New Relic对以下五个方面进行了调查分析，分别是：生产中使用最多的版本、最受欢迎的供应商、容器的兴起、最常见的堆大小配置和最常用的垃圾收集算法。

报告中的数据完全来自于2022年1月向New Relic报告的应用程序，并不代表Java使用情况的全貌。New Relic对适当的数据进行了匿名和刻意粗粒度的处理，以提供对Java生态系统的总体概况。另外，报告中刻意排除了任何可能有助于攻击者和其他恶意行为的详细信息。

以下为《2022年Java生态系统状况报告》的详细内容：

Java 11 接班 Java 8，成最受欢迎版本

在2020年发布的报告中，尽管当时Java 11已经发布了一年多，但绝大多数应用程序仍在使用Java 8（占比84.48%）。但自那时起，这两个LTS版本之间的占比开始发生了变化。

数据显示，现在有超48%的应用程序在生产中使用Java 11（高于2020年的11.11%），Java 8紧随其后，占比46.45%。Java 17的排名目前还不是很高，但它在发布后的几个月里，已经超过了Java 6、Java 10和Java 16版本的占比。

每个Java LTS版本的使用百分比

另外，对Java 7的支持将在2022年结束，但仍有1.71%的应用程序在生产中使用它。同时，还有0.27%的应用程序在使用已经EOL的Java 6。不过，目前大多数正在使用Java 6和Java 7的一般都是尚未升级的遗留应用程序。

Java 14是最流行的非LTS版本

从Java 9开始，Java平台的发布模式就发生了变化，每六个月就会推出一个新版本的Java。但为了更频繁地提供新功能，这些版本的支持周期一般只持续到下个新版本的推出。

然而，与生产中的LTS版本相比，临时的、非LTS的Java版本使用率仍然非常低，只有2.7%的应用程序使用非LTS的Java版本。虽然Azul Systems等供应商会为一些非LTS版本提供补丁，但大多数供应商并没有这样做。这可能就是很多用户不愿意升级的原因。

每个Java非LTS版本的使用百分比

在使用的非LTS Java版本中，Java 14是最受欢迎的，Java 10和Java 16并列垫底。

甲骨文份额萎缩，亚马逊正在崛起

近年来，使用Java开发工具包（JDK）的发行版来源发生了变化。以前许多开发者会从甲骨文获得JDK，而现在OpenJDK项目中Java的开源为开发者们带来了大量的选择。

从下图可以看出，在甲骨文对JDK 11发行版进行更严格的许可后（又在Java 17中恢复更开放的立场前），开发者从甲骨文中转移二进制文件的情况。

2020年，甲骨文是最受欢迎的供应商，约占Java市场的75%。虽然现在保留住了头把交椅，但份额已经萎缩至原来的一半以下。与此同时，Java之父就职的亚马逊公司的市场份额已经大幅攀升到22.04%（2020年占比为2.18%）。

各供应商使用的JDK发行版的百分比

自2021年11月以来，除了总体远离甲骨文的趋势，这些数字还发生过有趣的变化。那就是，在Java 17发布之前，Eclipse Adoptium和亚马逊在这个列表中几乎处于完全相反的位置。

容器运行成主流

容器化应用程序已经成为主流，New Relic的Java应用数据也证明了这一点。据报告显示，Java应用中70%以上是基于容器运行的。

• 容器中的计算设置

容器影响人们分配计算和内存资源的方式。例如，报告数据显示，在容器中运行的应用程序，少于四个核心的比例要高很多。

按内核数量划分，在容器内和容器外运行的应用程序的百分比

在人们经常部署容器的云环境中，运行小型化的驱动力很有意义。但这种趋势可能会给一些应用程序带来意想不到的问题。特别是当使用两个以下的内核运行时，最新Java虚拟机（JVM）上默认G1垃圾收集器的许多并发优势会消失。所有这些单核实例可能都在使用串行收集器并为此付出性能成本，但许多开发者可能根本不知道。

• 容器中的内存设置

比较内存设置时也会出现类似的趋势，在容器中往往倾向于更小的实例。

容器内和容器外运行的内存设置堆大小的百分比

报告数据显示，只有大约80%的容器化应用程序通过-Xmx或-XX:MaxRAMPercentage标记明确要求JVM内存上限。从Java 9开始，JVM中的容器感知功能意味着，只要JVM是每个容器中唯一运行的进程，那它对应用程序来说，就不会像以前那样成为安全问题。

G1是最受欢迎的GC算法

鉴于垃圾收集（GC）在JVM性能中发挥核心作用，所以其仍是社区中讨论最多的一个话题。

New Relic的数据显示，Java 8之后，垃圾收集器的使用发生了明显变化。考虑到Java 11及更高版本的G1收集器有更新的默认值和更高的性能，所以G1受开发者欢迎并不令人惊讶。

Java 10或更早版本与Java 11或更高版本使用的GC算法的百分比

显然，出于对G1的喜爱，很多开发者才会选择抛弃Java 8。另外，在预料之中的是，其他在Java 8之后出现的实验性收集器（ZGC和Shenandoah）在生产系统中的使用量仍然很小，毕竟这两个收集器直到最近才达到生产就绪状态。

报告链接：

• https://newrelic.com/resources/report/2022-state-of-java-ecosystem