2022 年 Java 行业分析报告

作者：看山

2022 年 6 月 19 日
本文字数：4315 字
阅读完需：约 14 分钟

你好，我是看山。

前段时间介绍了从 Java8 到 Java17 每个版本比较有特点的新特性（收录在从小工到专家的 Java 进阶之旅专栏），今天看到 JRebel 发布了《2022 年 Java 发展趋势和分析》，于是借此分析一下 Java 行业的现状，希望给大家一些参考。

JRebel 是通过调研问卷的方式总结的报告，涉及了不同国家、不同岗位、不同公司规模、不同行业，相对来说，该调查报告是有一定参考意义的。

Java 语言及开发趋势

Java8 的占比还是比较高

我们先来看下大家都在使用的 Java 版本（包括 JVM 语言：Kotlin、Groovy、Scala）：

从结果我们可以看到，Java8 占比 37%，Java11 占比 29%，甚至有 12%的被调查者使用了高于 Java12 的版本。

Java8 是 2014 年发布，相较于之前版本，增加了 Lambda 表达式、Stream 流式处理等一种优秀的 API。至今已 8 年时间，Java 版本也是从 8 一直升到了 17。版本号一直在增加，却没有增加特别吸引人的语言特性。

哪些因素是大家升级的动力呢？

可以看到，主要的升级因素包括 LTS 版本（25%）、安全性（23%）、性能（20%），新特性（18%）和随大流（14%）占比低一些。

从这点我们也就知道为什么 Java11 之后的版本占比并不高了，随着 Java17 的发布，可能 Java8 和 Java11 的占比会降低。安全性方面，除非是严重的漏洞，一般 Java 开发团队会通过补丁的方式升级，不会影响大版本号占比。

性能方面，Java 团队一直在不断优化，随着 G1、ZGC、Shenandoah 等一众优秀的 GC 被添加进来，这也成为大家从 Java8 升级的重要原因。

就功能特性而言，Java11 之后增加了 Record 类型、密封类、instanceof 模式匹配、Swtich 表达式和模式匹配等一些语法糖。这些新特性，也能够提升升级到 Java17 的意愿。

升级 Java17 的意愿还是比较强的

Java17 是 2021 年下半年发布的 LTS 版本（长期支持版）。

我们看下大家升级的意愿：

从结果可以看出来，有 37%的人会在未来 6 个月内升级，有 25%的人会在 6-12 个月内升级，不会升级的占比仅占 8%。

可见，有 62%的人会在未来一年内升级到 Java17，大家的升级意愿还是比较强的。

OracleJDK 和 OpenJDK 占据过半市场

我们都知道，市面上有很多的 JDK 版本，在 Oracle 起诉 Google 侵权之前，非企业特供的情况下，我们基本上用的都是 OracleJDK，后来因为容器中使用 JDK 版本的版权问题，容器中大部分使用了 OpenJDK。

从问卷结果也反映了这种情况：

OracleJDK 的版本占比 36%，OpenJDK 的版本占比 43%，其中包括标准 OpenJDK 和 AdoptOpenJDK 版本。

有些同学会疑惑 OracleJDK 和 OpenJDK 的区别在哪？我们日常用到的部分，没有任何区别。

Java 应用架构趋势

这个问题的结果有些出乎我的预料：

各种架构风格中，微服务架构仅占 32%，单体架构占比 22%，模块化单体架构占比 13%，SOA 架构占比 12%。

从结果来看，这个问卷的对架构风格的定义和分类比较细腻。

很多公司把系统的服务化、模块化也统称为了微服务，这是一种很严重的错误，在之前的文章《微服务架构的陷阱：从单体到分布式单体》中介绍过这种错误。

微服务架构趋势

既然微服务架构占比高一些，我们就来看一下微服务架构的应用趋势。

微服务架构的应用状态

从结果来看，有 44%的人团队已经是完全微服务架构了，还有 44%的团队在向微服务架构迁移。可见，在 Java 行业中，微服务架构是得到大家普遍认可的。

但是这个结果与上面的架构风格占比结果有出入，可能是问卷题目设计问题，或者问题回答者的主观原因，不能够苛求结果准确性。

每个应用中微服务的数量

既然是微服务架构，每个应用中服务数量必然超过 1 个。从结果可以看出来，有 54%的应用中少于 10 个服务，还有 22%的应用服务数量超过 20 个。

按照公司规模维度，越是大公司，每个应用中服务数量越多，结果符合康威定律的。从大家普遍实践结果看，当团队规模较小时，要尽量减少微服务数量。市面上很多老师会告诉我们，微服务架构要按照业务域拆分，但是你要知道，如果团队规模不大，即使拆分了业务域，可能最终开发调试维护也只有你一个。

SpringBoot 几乎霸占了整个微服务市场

从结果看，SpringBoot 几乎霸占了整个微服务市场。所以，大家在日常工作学习过程中，还是主要看看 SpringBoot 栈吧。

在国内，SpringBoot 技术栈还会细分为 SpringNetflixCloud 栈、SpringAlibabaCloud 栈、SpringBoot+Dubbo 栈等。

不同的技术栈中组件有些差异，所以我们需要掌握的不是简单的应用，还要了解其中的原理。原理掌握了，不同的组价只是在应用层面的差异。

启动时间在增长

随着公司业务的增长，应用中会增加各种各样的新功能。问卷中有个问题是关于随着时间推移，微服务启动时间的变化：

可见，有 60%的服务启动时间都在增加，甚至有 13%的应用启动时间增长超过 50%，有 30%的应用启动时间增长范围在 10%-50%。

为什么启动时间会增长呢？这个与公司业务增长后，代码增加了很多新功能有关。随着功能增加、类的增加，系统体积增大、加载类数量增大，启动时间会随之增加。这会引起系统的腐化，当腐化到一定程度，可能就需要重构了。或者随着业务增长，原来的微服务边界划分不合适了，需要重新划分系统边界，拆分微服务。

启动需要多长时间

既然微服务总体的启动时间在增长，那启动时间一般是多久呢？

可以看到，只有 9%的服务在 1 分钟内启动成功，有 26%的服务启动时间需要 10 分钟以上。

从上图可以看出来，人员规模大于 100 人的公司中，服务启动时间普遍长于少于 100 人的公司。产生这种情况的原因有这么几个：

公司规模大一些，可能业务复杂一些，服务中的代码、类库更多一些；
公司规模大一些，依赖的组件更多一些，在服务启动时，需要与各种中间件建立链接，然后彼此交换成功心跳，自然需要时间更多。

采用微服务其中一个好处是服务足够小，启动时间比较少。但是，从上面两个问卷结果来看，普遍情况是启动时间比较长，而且在变得更长。

Java 技术趋势

Java 应用超过半数使用了容器部署

从问卷结果可以看到，Docker 使用率是 41%，Kubernetes 使用率是 26%，VMware 使用率是 16%，Vagrant 使用率是 3%，即有 86%已经实现了虚拟化，其中 Docker、Kubernetes 占比最高。

所以在 Java 升级版本特性中，实现了容器感知的能力，使 Java 服务容器化更容易一些。

PaaS 平台还得看 AWS

JRebel 的这个问卷调查是全球性质的，从全球范围看，AWS 当之无愧的 NO.1。AWS 作为亚马逊曾经的附属产业，已经成为了亚马逊的重要业务之一。

与亚马逊的经历类似，阿里巴巴从电商切入，然后布局云服务（阿里云）。如果还是走亚马逊的老路，势必没法超越。不过阿里从很多年前开始布局 CPU 和芯片领域，如果能够有所突破，就可以破开西方技术的封锁，依托我国的发展潜力，未必不能撼动亚马逊的 PaaS 服务商地位。

近半数服务端使用 Tomcat 容器

前面关于微服务的问题中，SpringBoot 是众多微服务框架中的首选，SpringBoot 默认的应用容器是 Tomcat。加之 Tomcat 的开源方式，将近半数应用服务器选择 Tomcat 也是预料之中。

Maven 是主要的构建工具

Maven 和 Gradle 到底该用哪个？这个问题似乎争论许久。从问卷结果看，Maven 占有率是 68%，Gradle 占有率是 23%，Maven 还是有绝对的优势。

Gradle 采用了约定大于配置的方式，与 SpringBoot 的理念一致。但是从市场接受度和发展而言，并没有形成替换 Maven 的风潮。Android 项目默认使用 Gradle，能够看出 Google 对 Gradle 的推崇，也从侧面印证 Gradle 的优秀。但是，Gradle 并没有绝对优势。

近半数开发者使用 IntelliJ IDEA

我是从 2015 年开始使用 IntelliJ IDEA，试用之后立马抛弃了 Eclipse。首先是快捷键的设计，可以很大程度摆脱鼠标。内置的插件市场，可以找到任何需要的插件，提升编程体验。更关键的是，JetBrains 公司出品的 IDE，可以无缝对接，实现不同语言的编程支持。

Eclips 也不是一无是处，它的插件体系也是相当丰富，很多低代码开发工具都是基于 Eclipse 开发的。如果是普通开发，推荐使用 IntelliJ IDEA；如果想要做低代码工具，可以考虑对 Eclipse 进行二次开发。

开发者生产力趋势

这一部分属于 JRebel 有私心的部分，JRebel 一个优势功能是提供热部署能力，所以会在问卷中询问被调查者重新部署应用的时间。

重新部署应用的时间

很多时候，我们可能只改动一行代码，然后验证功能是不是正常，这个时候需要重新部署应用。JRebel 统计了重新部署需要花费的时间。

从结果上看，重新部署需要超过 3 分钟时间的占 50%，其中 21%的比率需要 10 分钟以上。那这段时间，大家会干什么？

如果节省重新部署的时间你会做什么？

有 28%会增加新功能；有 20%会优化系统性能；有 19%会完善测试覆盖。这些都是正向的，大概率的是那些回答其他的：喝咖啡、喝啤酒、开趴、睡觉、钓鱼……

不过也是符合我们工作的原因：我们工作是为了生活，而不是为了加班。所以，假如每天给你 1 小时的自由时间，你会用来做什么呢？欢迎评论区讨论。

文末总结

微服务的使用情况来看，启动时间和重新部署时间不是优先考虑的因素。多数选择微服务架构的原因无非有两个：
看中微服务架构流行趋势，听说这个很好，那就开始用，至于是微服务架构还是分布式单体架构，就不重要了；
微服务的优势能够弥补带来的弊端，比如业务迭代速度等；
微服务收康威定律影响比较大；
技术在不断革新，但是大家会比较理性地接受。公司规模越大，越趋于选择成熟的技术；
容器已经是大势，需要掌握。

技术不断发展，我们需要学习的东西越来越多，很多时候感觉学不动了。但既然选择了这个行业，拿着高于其他行业的薪资，也承担着各种裁员的风险，总归是要有一些技能傍身，才不至于被历史的车轮碾成粉末。

青山不改，绿水长流，我们下次见。

创作场景