2022 年 Java 行业分析报告

你好,我是看山。

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

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

Java 语言及开发趋势

Java8 的占比还是比较高

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

Java 各版本语言占比

从结果我们可以看到,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 版本(长期支持版)。

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

升级 Java17 的意愿

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

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

OracleJDK 和 OpenJDK 占据过半市场

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

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

JRE/JDK 各种版本的市场份额

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

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

Java 应用架构趋势

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

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. 公司规模大一些,依赖的组件更多一些,在服务启动时,需要与各种中间件建立链接,然后彼此交换成功心跳,自然需要时间更多。

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

Java 技术趋势

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

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

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

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

PaaS 平台还得看 AWS

PaaS 平台

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

IDE

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

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

开发者生产力趋势

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

重新部署应用的时间

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

重新部署应用的时间

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

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

重新部署时大家在做什么

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

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

文末总结

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

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

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

参考

推荐阅读


你好,我是看山。游于码界,戏享人生。如果文章对您有帮助,请点赞、收藏、关注。我还整理了一些精品学习资料,关注公众号「看山的小屋」,回复“资料”即可获得。

个人主页:https://www.howardliu.cn
个人博文:2022 年 Java 行业分析报告
CSDN 主页:https://kanshan.blog.csdn.net/
CSDN 博文:2022 年 Java 行业分析报告

👇🏻欢迎关注我的公众号「看山的小屋」,领取精选资料👇🏻

公众号:看山的小屋