概述
现代软件行业规模庞大,毫不缺乏供人选择的编程语言。而Java
仍在软件开发人员中深受欢迎,因为它不仅独立于平台,可以轻松的从一个计算机系统迁移到另一个计算机系统,同时还提供了数千个工具库,并能到很好的技术资源支持,所以它几乎被使用于各行各业以及经济部门中。
2022
年3
月,New Relic
发布了第一份 Java 生态系统状况报告,该报告基于从数百万个提供性能数据的应用程序中收集的数据。 Java 17
的最新版本(Java 11
以来的第一个长期支持(LTS)版本)提供给了我们重新审视这个数据的机会。为了得出这份报告,New Relic
对数据进行了适当的脱敏处理和降低颗粒度处理,来达到提供Java
生态系统总体概述的目的。而且任何帮助攻击者或者其他恶意方的详细信息都被特意排除在报告之外。
本报告的目的是提供有关当今Java
生态系统状况的背景和见解,主要包括以下几点:
- 生产环境下最常用的版本
- 最受欢迎的供应商
- 容器技术的兴起
- 最常见的堆大小配置
- 最常用的垃圾回收算法
Java 11 已成为新标准
到2020
年为止,尽管Java 11
已经推出一年多的时间了,但是绝大多数(大约84.48%)应用程序仍然在使用Java 8
。但之后,两个LTS
版本之间的比例也在慢慢发生变化。现在,超过48% 的应用程序开始在生产环境下使用Java 11
(远高于2020年的 11.11%),Java 8
则紧随其后,6.45% 的应用程序开始在生产环境下使用该版本。
Java 17
并没有登上榜单,但是在发布后的几个月内,它已经先后超过了Java 6
、Java 10
和 Java 16
版本
对Java 7
的官方支持将在2022年结束,但仍有1.71% 的生产级应用程序在使用它。同时,不再受支持的Java 6
,也有0.27% 的生产级应用在使用,大多数使用这两个版本的应用都是属于未升级的遗留应用程序。
Java 14 成为最后欢迎的非LTS 版本
从Java 9
开始,Java
平台的发布模式开始发生改变。每六个月就会有一个新的Java
版本发布并可供使用,但仅支持到下一个版本。这么做的目的是为了加快新功能的更新可用。
但是,与生产环境下的LTS版本相比,这些临时性的非LTS版本的使用率仍然极低。目前,只有2.7% 的应有程序在使用这些版本。虽然Azul Systems
等一些供应商在某些非LTS版本上提供更新补丁,但是大多数供应商并没有这么做,缺乏一定的可靠性。这可能也是大多数用户不愿意升级的原因。在被使用的所有非LTS版本中,Java 14
是最受欢迎的。而Java 10
和Java 16
则居于垫底位置。
Oracle 人气下降,Amazon 正在崛起
近年来,使用Java
开发工具包(JDK)的各个发行版的来源也在发生变化。过去时间里,大多数开发人员会从Oracle
那里获取JDK
。现在,OpenJDK
开源项目也为开发者带来了更加丰富的获取渠道的选择。
在下表中,显示了在JDK 11
发行版制定出了更严格的许可条款后(在Oracle
此后又在 Java 17
中转回更加开放的立场之前),开发者从Oracle
获取源码以及到其他途径的比例变化。2020
年,Oracle
成为最受欢迎的供应商,大约占据市场的75%,但是现在,虽然Oracle
仍然占据头把交椅,但是他们的份额已经缩为原来的一半。Amazon
的市场份额则大幅攀升至22%(远高于2020年占据的2.18%)
另外,自 2021 年 11 月以来,还从这些数字的变化中发现了一个有趣的现象,在Java 17
发布之前,lipse Adoptium
和 Amazon
在列表中处于几乎进行了调换。
容器已经无处不在
应用程序的容器化趋势已经成为主流,New Relic
的 Java
应用程序数据也证明了这一趋势。从New Relic
的报告看,超过 70% 的 Java
应用程序是以容器的形式运行的。
容器中的计算设置
容器技术在影响着人们分配计算资源和内存资源的方式。例如,在New Relic
的数据中显示,在容器中运行占有4个或者以下内核的应用程序占据了很大比例。
在部署了大量容器的云环境中,运行这些小规格的程序具有现实意义。但是这种趋势也会给某些应用程序带来意想不到的问题。例如,当使用少于两个的内核工作时,最新的Java
虚拟机(JVM)上默认的G1垃圾回收器
的并发优势就会得不到发挥,所有的单核心实例只能串行的使用回收器并为此付出相应的性能成本,而大多数开发者目前并没有意识到这种情况。
容器中的内存设置
相对比,内存方面也出现了类似的趋势。容器中的实例规格往往更小。从New Relic
的数据显示,只有大约80% 的容器化应用程序通过-Xmx
或者-XX:MaxRAMPercentage
标识明确的设置了JVM
的内存上限。从版本 9开始,JVM
中引入的容器感知功能可能导致这些应用程序出现安全问题。但是如果每个容器中只运行了JVM
这一个进程,那么引入的容器感知功能将不会有影响。
垃圾回收
鉴于其在JVM
中性能的核心作用,垃圾回收(GC)在社区中仍然是个被讨论很多的问题。
New Relic
的数据显示,在Java 8
之后垃圾回收器使用得到了明显的提升。考虑到Java 11
以及更高版本上的G1回收器
不仅更新了默认值,而且性能也得到了提示,所以这并不奇怪。
可以看出,G1
也是吸引开发者放弃Java 8
的一个因素。虽然在Java 8
之后出现的其他实验性回收器(例如ZGC
和 Shenandoah
)在生产环境中的使用量仍然很小,但是这是在意料之中的,因为他们还没达到生产状态。
统计方法
本报告的数据完全来自于 2022
年 1
月 New Relic
收集到的应用程序数据,并未提供Java
的总体使用趋势。同时 New Relic
对适当的数据进行脱敏处理并降低粒度处理,来提供对Java
生态系统的总体概述。另外,任何可以帮助攻击者和其他恶意方的详细信息都被已经排除在报告之外。
关于该报告更多详细信息:请参考:newrelic.com/resources/r…