最新 Java 生态现状报告：甲骨文份额骤缩超一半，Java11 首超 Java8！

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

2020年3月，New Relic 基于数百万个提供性能数据应用程序中收集到的数据，发布了首个《Java 生态系统状况报告》。

而随着自 Java11 以来首个长期支持（LTS）版本——Java17 的发布，以前所收集到的数据都要重新审视。

在报告中，New Relic 对部分敏感数据进行了“脱敏”处理并故意拉低颗粒度，希望借此整理出对于 Java 现有生态系统的总体概况。

报告称，虽然现代规模庞大的软件业中不乏可供选择的编程语言，但 Java 始终广受软件开发人员的欢迎，几乎覆盖了各大主要行业及经济部门的所有细分领域。

在2020年首次发布的报告中，当时 Java11 已经发布了一年多，但绝大多数应用程序仍在使用 Java8，占比高达 84.48%。

不过，自那时开始，这两个 LTS 版本之间的占比便开始发生了变化。

全新数据显示，现在有超 48% 的应用程序在生产中使用 Java11，而 Java8 紧随其后，占比 46.45%。

此外，Java17 的排名目前还不是很高，但它在发布后的几个月里，已经超过了 Java6、Java10 和 Java16 的版本的占比。

对 Java7 的官方支持将在2022年内结束，但仍有 1.71% 的生产级应用在继续使用；另外，不再受到支持的 Java6 也占据着 0.27% 的生产级应用份额。

大部分使用 Java6 和 Java7 的都属于未经升级的遗留应用程序。

自 Java9 开始，Java 平台的分布模式就发生了变化。每六个月就会有新的 Java 版本面世，但支持周期仅延续至下个新版本推出。这显然是为了加快新功能的上线速度。

与生产环境下的 LTS 版本相比，临时性非 LTS 版本的使用率仍然极低，目前只有 2.7% 的应用程序在使用非 LTS 的 Java 版本。

虽然 Azul Systems 等供应商也会为某些非 LTS 版本提供更新补丁，但仍然缺乏可靠的普遍意义。

这可能也解释为什么大部分用户并不愿意为了非 LTS 版本而快速升级。

在所有非 LTS 版本中，最受欢迎的 Java14，而 Java 0 与 Java16 则并列垫底。

近年来，使用 Java 开发工具包（JDK）的发行版来源发生了变化。

以前许多开发者会从甲骨文获得 JDK，而现在 OpenJDK 项目中 Java 的开源为开发者们带来了大量的选择。

可以看出，在甲骨文对 JDK11 发行版进行更严格的许可后，开发者从甲骨文中转移二进制文件的情况。

2020年，甲骨文是最受欢迎的供应商，约占 Java 市场的 75%。现在甲骨文虽然仍占据头把交椅，但份额已经萎缩至原来的一半以下。

与此同时，Java 之父现在就职的亚马逊公司的市场份额已经大幅攀升到 22.04%（2020年占比为2.18%）。

自2021年11月以来，除了总体远离甲骨文的趋势，这些数字还发生过有趣的变化。

那就是，在 Java17 发布之前，Eclipse Adoptium 和亚马逊在这个列表中几乎处于完全相反的位置。

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

容器技术也影响着人们分配计算和内存资源的方式。例如，New Relic 数据显示，容器中占用4 及以下计算核心数的应用程序基本占据了大部分比例。

对于部署有大量容器的云环境来说，运行这些小体量程序当然具有现实意义。但这种趋势也会给某些应用程序带来意想不到的问题。

例如，当使用的核心少于2个时，最新 JVM 上的默认 G1 垃圾回收器就无法发挥其并发优势。

这些单核心实例往往只能使用串行回收器并承担相应的性能成本，但很多开发者可能根本意识不到。

2.容器中的内存设置

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

New Relic 数据显示，只有大约 80% 的容器化应用程序会通过 -Xmx 或者 -XX:MaxRAMPercentage 标记明确设定 JVM 内存上限。

从版本 9 开始，JVM 引入了新的容器感知功能，而且有可能引发安全隐患。但只要各容器中只运行 JVM 这一个进程，那么容器感知就不会影响应用程序的安全水平。