现代软件行业规模庞大，可供选择的编程语言所在多有。但 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 生态系统状况的背景与见解，具体着眼于以下几点：
- 生产环境下最常用的版本
- 最受欢迎的供应商
- 容器技术的兴起
- 最常见的堆大小配置
- 最常用的垃圾回收算法
到 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/，获取更多精彩内容！
,
