深度思考亚马逊(2022年Java)(1)

综述

现代软件行业规模庞大,可供选择的编程语言所在多有。但 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 这一个进程,那么容器感知就不会影响应用程序的安全水平。

垃圾进,垃圾出

鉴于在 JVM 性能中发挥的核心作用,垃圾回收(GC)在 Java 社区中仍是个颇具热度的话题。

New Relic 数据显示,Java 8 之后垃圾回收器的使用方式出现了明显提升。考虑到 Java 11 以及更高版本上的 G1 回收器不仅更新了默认值、更带来出色的性能提升,所以开发者们的支持也在情理之中。

也正是受到 G1 的吸引,很多开发者才毅然放弃 Java 8。虽然 Java 8 之后出现的其他实验性回收器(ZGC 与 Shenandoah)在生产系统中的使用频率仍旧不高,但相信到它们达到生产状态后,情况应该会有所改观。

统计方法

本份报告中列出的信息来自 2022 年 1 月 New Relic 收集到的应用程序数据,未必能反映 Java 语言的总体使用趋势。New Relic 已经对部分敏感数据做出脱敏和降粒度处理,希望整理出 Java 生态系统的总体概况。请大家放心,报告内不含任何有助于恶意攻击或者其他负面行为的素材。

原文链接:

https://newrelic.com/resources/report/2022-state-of-java-ecosystem?utm_source=reddit&utm_medium=community&utm_campaign=global-fy23-q1-state-of-java-ecosystem-report

了解更多软件开发与相关领域知识,点击访问 InfoQ 官网:https://www.infoq.cn/,获取更多精彩内容!

,