性能文章>重磅:解读2020年最新JVM生态报告>

重磅:解读2020年最新JVM生态报告原创

2年前
856313

这篇报告会回答下面这些,但不止这些问题:

  1. 你最近在生产环境中主要使用的哪个发行方的JDK?
  2. 你最近为JDK付费了吗?
  3. 你付费给谁了?
  4. 自JDK 9以来,支持和发布节奏的变化是否影响了您决定支持付费?
  5. 将来你会考虑为JDK付费吗?
  6. 你的项目主要使用哪个JDK版本?
  7. 你没有升级到最新JDK版本的原因是什么?
  8. 你的应用主要使用JVM生态的哪种语言?… …
  9. 你最近在生产环境中主要使用的哪个发行方的JDK?

随着甲骨文这个坏家伙修改了JDK的license,所以这第一个问题就非常重要了。通过报告可以看到Oracle JDK依然是NO.1,但是已经不是一家独大,毕竟连一半市场份额都没有。更可怕的是,相比2018年,OracleJDK下降了36%,而OpenJDK增长了36%。

image.png

你现在和将来为JDK付费了吗?

通过统计我们发现,现在只有9%的用户为JDK付费。Oracle看到这份报告估计想Cry。毕竟国内有阿里巴巴使用完全开源OpenJDK,国外有大名鼎鼎的谷歌用OpenJDK,还有号称最牛逼的Java开发工具IDEA自带的也是OpenJDK。两个JVM生态主要玩家都不用OracleJDK,这就为大家带了一个好头,哈哈哈:

image.png

备注:这些付费用户中,超过一半(55%)的用户是付费给Oracle,其次付费给RedHat有17%,付费给IBM的有16%,付费给Azul的有12%。

而将来愿意为JDK付费的用户也不多,如下图所示:

image.png

你的项目主要使用哪个JDK版本?

这个问题事实上不需要看结果我们都能猜到是JDK8,没错,就是它~是它是它就是它!绝对的JDK版本钉子户,哈哈哈~但是让我意外的是,JDK11的用户比例竟然达到了25%。

image.png

那么,大家不肯升级到新版JDK的原因是什么呢?排名第一的是当前JDK运行的蛮好的。第二原因是迁移代价太大。第三原因则是新版本特性没有很大的吸引力(JDK的用户还是蛮难伺候的):

image.png

遇到严重的安全问题你会多快升级JDK?

毕竟要让Java应用安全的运行,那么碰到严重的JDK安全问题升级就很有必要了!毕竟,远程攻击导致公司重大损失的事件每天都在发生。然后,仍然有17%的用户不愿意升级!任你千苍百孔,我自归然不动,哈哈哈!当然,还是有61%的用户在一个月以内就会升级解决安全问题:

image.png

你的应用主要使用JVM生态的哪种语言?

JVM已经成为一个生态了,运行在JVM之上的不只是Java语言,大名鼎鼎的kafka,Scala语言编写的,也是运行在JVM上。还有因为和甲骨文官司问题,谷歌力推的Kotlin,也是运行在JVM之上。当然,JVM上运行的语言,Java依然占据绝对地位,达到了86.9%,接近9成用户,恐怖:

image.png

使用Spring框架的比例

大概60%的用户在他们生产环境的项目中使用了Spring框架,这对于一个非官方的,完全属于第三方开发的开源软件来说,这是一个非常高的比例。完全可以说,Spring框架是Java生态中非常具有支配地位的框架:

image.png

这些使用Spring框架的用户中,使用的版本分布如下,接近一半的用户使用的是5.1.x版本,2/3左右的用户使用5.x版本。可见,使用Spring新版本的占比是非常高的:

image.png

其他语言占比

现在很多的项目不止使用一种开发语言。所以,现在的开发人员很有必要成为熟悉多种开发语言,全栈的软件工程师。

统计结果一点都不让人意外,JavaScript是最流行的前端开发语言,远超其他语言,占到62%的开发人员,其次是SQL占比44%,是最流行的数据库查询语言。然后是在数据科学和机器学习方面表现出色的Python,占比也有22%:

image.png

Web框架

我们先看客户端Web框架占比,各有千秋,没有哪个Web框架有绝对的统治地位。用的最大的3个客户端Web框架分别是:Angular,React,jQuery。如下图所示:

image.png

而服务端Web框架分布就要高度集中的多,这主要得益于Spring家族两大杀器:SpringBoot和SpringMVC(当然,SpringBoot默认也是采用的SpringMVC作为它的Web框架)。这俩家伙加起来占比超过80%,简直不给其他Web框架留下任何机会(为以前SSH之一的Struts默哀1分钟):

image.png

工具使用情况

我们首先看一下IDE开发工具,IDEA毫无悬念登顶,而且以超过60%的比例。Eclipse老而弥坚,还有20%:

image.png

再来看一下构建工具使用情况,Maven一家独大,其次是后起之秀Gradle,最后是Ant:

image.png

接下来是代码仓库,排名依次是:GitLab > GitHub > BitBucket:

image.png

角色分布情况

最后就是IT行业角色分布情况,超过一半是软件开发工程师,21%是架构师,14%是团队Leader角色。正在看此文的您,角色是什么呢?

image.png

报告PDF地址:https://snyk.io/wp-content/uploads/jvm_2020.pdf

请先登录,再评论

都是大佬,收小弟一拜!这应该是我在这个社区能看明白为数不多的文章了吧

12年前
回复 大大大鹏:

哈哈哈,经常看大佬们的知识沉淀,才会慢慢成为大佬。

2年前回复

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得