[转]2022 年 Java 行业分析报告

2022 年 Java 行业分析报告

你好，我是看山。

前段时间介绍了从 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 人的公司。产生这种情况的原因有这么几个：

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

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

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

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

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