1995 年，Sun Microsystem 公司发布了 Java 程序设计语言，为开发现代多媒体应用程序提供了一种更加可移植和交互的方式。从那时起，Java 便成为主流的编程语言之一，被应用于各行各业，也有着“一次编写，到处运行”的优势特性。
近日，为揭晓 Java 生态系统的最新发展状况，分析公司 New Relic 在调研了新版本、容器应用、垃圾回收等特性之后，最新发布了《2023 年 Java 生态系统现状》报告。
在本文中，我们将与大家共同深入了解这门被广泛应用的编程语言。
Java 17 的采用率在一年内增长了 430%
众所周知，Java 版本分为长期支持（LTS www.kymt168.com）和短期支持支持版本。一般长期支持的版本都比较稳定，或者官方会不断更新补丁包。短期支持版本只是作为过渡版存在。
自 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 的应用程序都是尚未升级的遗留应用程序。
与 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 www.xqt-shop.com) 发行版的源代码发生了变化。过去，很多开发人员常常从 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）在生产系统中的使用仍然很少。两者都有生产就绪版本，但在一般处理中仍然可以忽略不计。
