编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

1995 年，Sun Microsystem 公司发布了 Java 程序设计语言，为开发现代多媒体应用程序提供了一种更加可移植和交互的方式。从那时起，Java 便成为主流的编程语言之一，被应用于各行各业，也有着“一次编写，到处运行”的优势特性。

近日，为揭晓 Java 生态系统的最新发展状况，分析公司 New Relic 在调研了新版本、容器应用、垃圾回收等特性之后，最新发布了《2023 年 Java 生态系统现状》报告。

在本文中，我们将与大家共同深入了解这门被广泛应用的编程语言。

Java 17 的采用率在一年内增长了 430%

众所周知，Java 版本分为长期支持（LTS）和短期支持支持版本。一般长期支持的版本都比较稳定，或者官方会不断更新补丁包。短期支持版本只是作为过渡版存在。

自 2017 年 Oracle 将 Java 版本的更新频率更改为六个月一次时，长期支持 LTS 版本大概 2-3 年更新一次。不过，这种高频的更新率让无数网友怨声载道，学不动的声音不绝于耳，以至于很多人呈现出“你更任你更，我不用”的“摆烂”状态。

这不，Oracle 在今年 3 月最新发布了 Java 20 版本。不过，据最新数据报告显示，Java 11 已连续两年位居榜首，成为开发者最常用的 Java 版本。

当下，超过 56% 的应用程序在生产中使用 Java 11，这一比例要高于 2022 年的 48% 和 2020 年的 11%。

Java 8 的使用率紧随其后，近 33% 的应用程序在生产中使用它（低于 2022 年的 46%）。

虽然 Java 11 稳居第一，但是最新的 LTS 版本 Java 17 的采用率逐年攀升，从去年不到 1% 的比例，迅速增长至今年的超过 9% 的占比。研究报告显示，Java 17 在过去一年内增长率为 430%，而彼时 Java 11 花了数年时间才达到那个水平。

相较之下，只有 0.28% 的应用程序仍在生产中使用 Java 7。这并非没有根由，究其原因，是因为官方对 Java 7 的支持已于 2022 年结束。大多数使用 Java 7 的应用程序都是尚未升级的遗留应用程序。

Java 14 是最受欢迎的非 LTS 版本

与 LTS 版本相比，短期的非 LTS Java 版本的使用率仍然极低，只有 1.6% 的应用程序使用非 LTS Java 版本（低于 2022 年的 2.7%）。

根据报告调研发现，可能导致影响非 LTS 版本使用率下降的一些因素包括：

• 缺乏支持

• 缺乏吸引力的新功能

• 距离下一个 LTS 版本发布的时间太短

曾几何时，Java 8 发布了之后，外界并不能知晓下一个 LTS 版本 Java 11 会什么时候发布。不过，后来 ，Oracle 明确做出承诺：六个月一次更新，自此大家都有了清晰的认知，自然宁愿等等下一个 LTS 版本，也不愿在生产环境使用不稳定的非 LTS 版本。

数据显示，在使用的非 LTS Java 版本中，Java 14 仍然是最受欢迎的，占比0.57%（低于 2022 年的 0.95%），Java 15 紧随其后（0.44%，低于 2022 年的 0.70%）。

亚马逊现在是最受欢迎的 JDK 供应商

近年来，使用的 Java Developer Kit (JDK) 发行版的源代码发生了变化。过去，很多开发人员常常从 Oracle 获得他们的 JDK，但是 Oracle JDK 后来针对商业应用采取收费政策，这也让很多人望而却步，好在 OpenJDK 项目日渐丰富，成为众人的选择。

调查数据显示，2020 年，Oracle 是最受欢迎的 JDK 供应商，约占 Java 市场的 75%。在其 JDK 11 发行版的许可更严格之后（在 Java 17 回归更开放的立场之前），业界开发者开始逐渐远离 Oracle。虽然 Oracle 在 2022 年以 34% 的份额保持榜首，但在 2023 年下滑至 28%。

与之形成鲜明对比的是，Amazon 的使用率急剧上升至 31% 的市场份额（从2020 年的 2.18% 和 2022 年的 22%），使其成为最受欢迎的 JDK 供应商。

容器统治一切

容器化应用程序已成为主流，据 New Relic 调研显示，70% 的 Java 应用来自容器。

容器会影响工程团队分配计算和内存资源的方式。例如，New Relic 数据显示，在容器中运行的应用程序少于 4core 的比例要高得多。

工程团队正在摆脱容器中的单核设置，只有 36% 在使用（低于 2022 年的 42%），并转向多核设置，超过 29% 使用 8core 设置（高于 2022 年的 20%）。

工程团队通常在他们经常部署容器的云环境中使用较小的计算设置。但是，这种趋势可能会给某些应用程序带来意想不到的问题，这可能会导致配置减少。例如，如果团队只使用一个 CPU，他们可能得不到他们期望的垃圾收集器——即使他们明确地设置了它。

垃圾回收

自动垃圾收集是查看堆内存、识别哪些对象正在使用、哪些未使用以及删除未使用对象的过程。 鉴于其在 JVM 性能中的核心作用，垃圾回收仍然是 Java 社区中的热门话题。

New Relic 数据显示，Garbage-First (G1) 垃圾收集器仍然是使用 Java 11 或更高版本的用户的最爱，65% 的客户使用它。G1 的主要好处之一是，它清除较小的区域而不是一次性清除大区域，从而优化了收集过程。它还很少冻结执行并且可以同时收集年轻代和老年代，这使它成为工程师的一个很好的默认设置。

其他在 Java 8 之后出现的实验性垃圾收集器（ZGC 和 Shenandoah）在生产系统中的使用仍然很少。两者都有生产就绪版本，但在一般处理中仍然可以忽略不计。

完整的报告内容详见：https://newrelic.com/sites/default/files/2023-04/new-relic-2023-state-of-the-java-ecosystem-2023-04-20.pdf

推荐阅读：

▶起底ChatGPT账号生意：成本3块卖30，有人月赚20万；马斯克本周访华，系三年来首次；Qt 5.15 LTS结束|极客头条

▶因用 ChatGPT 打官司，从业 30 年的律师反遭制裁：6 个案例全是假的！

▶Rust 社区管理再起“内讧”，外部专家遭排挤，核心成员主动请辞，立即生效！