Java生态现状报告之甲骨文人气不再，亚马逊正在崛起

水深无声 2023-09-29 13:16 7阅读 0赞

现代软件行业规模庞大，可供选择的编程语言所在多有。但 Java 在软件开发者内仍然大受欢迎，几乎覆盖了各大主要行业及经济部门的所有细分领域。

究其原因，Java 语言拥有强大的平台独立性，能够轻松从一个计算机系统迁移至另一个系统，同时提供成千上万工具库与良好的技术支持资源。

去年 3 月，New Relic 发布首份 Java 生态现状报告（https://newrelic.com/blog/nerd-life/state-of-java），从数百万款应用程序中收集到第一手数据。

作为自 Java 11 以来推出的第一个长期支持（LTS）版本，Java 17 的亮相也促使我们时隔两年再来一轮总结。

查看报告全文：

https://newrelic.com/sites/default/files/2022-04/new-relic-report-state-of-the-java-ecosystem-april-2022.pdf

在报告中，New Relic 对部分敏感数据进行了脱敏处理、同时故意拉低颗粒度，希望整理出 Java 生态系统的总体概况。请大家放心，报告内不含任何有助于恶意攻击或者其他负面行为的素材。

这份报告希望帮助大家理解当前 Java 生态系统状况的背景与见解，具体着眼于以下几点：

生产环境下最常用的版本

最受欢迎的供应商

容器技术的兴起

最常见的堆大小配置

最常用的垃圾回收算法

图片  
Java 11 已成新标准

到 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 7 的官方支持将在 2022 年内结束，但仍有 1.71% 的生产级应用在继续使用。另外，不再受到支持的 Java 6 也占据着 0.27% 的生产级应用份额。大部分使用 Java 6 和 Java 7 的都属于未经升级的遗留应用程序。

图片  
Java 14 成为最受欢迎的非 LTS 版本

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

但与生产环境下的 LTS 版本相比，临时性非 LTS 版本的使用率仍然极低，目前只有 2.7% 的应用程序在使用非 LTS 的 Java 版本。虽然 Azul Systems 等供应商也会为某些非 LTS 版本提供更新补丁，但仍然缺乏可靠的普遍意义。这可能也解释为什么大部分用户并不愿意为了非 LTS 版本而快速升级。在所有非 LTS 版本中，最受欢迎的 Java 14，而 Java 10 与 Java 16则并列垫底。

图片  
甲骨文人气不再，亚马逊正在崛起

近年来，使用 Java 开发工具包（JDK）各发行版的来源也出现了变化。以往，大部分开发者会从甲骨文那边获取 JDK，但现在 OpenJDK 项目正推动开源 Java 迎来更广阔的发布渠道。

下表所示，是针对 JDK 11 发行版制定出更严格的许可条款后，开发者获取 JDK 的渠道比例变化（顺带一提，甲骨文此后又在 Java 17 中转回更加开放的管控立场）。

2020 年，甲骨文成为最受欢迎的 Java 供应商，在整个 Java 市场上占比约 75%。现在虽然甲骨文仍是头把交椅，但份额已经萎缩至两年前的一半。亚马逊的市场份额则从 2020 年的 2.18%，大幅攀升至现在的 22%。

除此之外，自 2021 年 11 月以来，我们还从数字波动中发现了另一个有趣的现象——在 Java 17 发布之前，Eclipse Adoptium 与亚马逊在列表中的排名和比例经历了一次互换。

图片  
容器已经无处不在

应用程序的容器化趋势已经成为主流，New Relic Java 应用程序数据也证明了这一判断。由报告来看，目前超过 70% 的 Java 应用程序以容器形式运行。

容器中的计算设置

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

对于部署有大量容器的云环境来说，运行这些小体量程序当然具有现实意义。但这种趋势也会给某些应用程序带来意想不到的问题。例如，当使用的核心少于 2 个时，最新 JVM 上的默认 G1 垃圾回收器就无法发挥其并发优势。这些单核心实例往往只能使用串行回收器并承担相应的性能成本，但很多开发者可能根本意识不到。

容器中的内存设置

内存设置方面也出现了类似的趋势，容器中的实例往往体量更小。New Relic 数据显示，只有大约 80% 的容器化应用程序会通过 -Xmx 或者 -XX:MaxRAMPercentage 标记明确设定 JVM 内存上限。从版本 9 开始，JVM 引入了新的容器感知功能，而且有可能引发安全隐患。但只要各容器中只运行 JVM 这一个进程，那么容器感知就不会影响应用程序的安全水平。

图片

![05][]

![图片 垃圾进，垃圾出 JVM （GCJava][_ JVM _GCJava]  
本份报告中列出的信息来自 2022 年 1 月 New Relic 收集到的应用程序数据，未必能反映 Java 语言的总体使用趋势。New Relic 已经对部分敏感数据做出脱敏和降粒度处理，希望整理出 Java 生态系统的总体概况。

[05]: https://img-blog.csdnimg.cn/33ab64f65d1849b698b68ea9ae38e0f9.png
[_ JVM _GCJava]: https://img-blog.csdnimg.cn/219a2a3468d04e21918b9c9668aa29ef.png