JDK8升级JDK11最全实践干货来了

jdk8,升级,jdk11,最全,实践,干货 · 浏览次数 : 151

小编点评

**依赖模块-a.jar** * **exports com.jdt.a.person;** * **opens com.jdt.a.refect;** **依赖模块-b.jar** * **requires module.a;}** **问题** * **为什么模块化后,就找不到了呢?** **解决方案** * 联系JSF团队,升级JSF包,修复上面说的FastJsonAutoDiscoverable配置错误的问题。 **拆包问题** * **当使用解析可传递依赖项的构建工具(如Maven等)时,容易出现同一个库的多个版本,当Java模块系统检测到一个包存在于模块路径上的多个模块中时,就会拒绝启动。** **解决方案** * 在使用模块化时,遇到拆分包问题,无论如何都是无法绕过的。即使从用户角度来看基于类路径的应用程序可以正确工作,你也最终需要处理这些问题。

正文

1、前言

截至目前(2023年),Java8发布至今已有9年,2018年9月25日,Oracle发布了Java11,这是Java8之后的首个LTS版本。那么从JDK8到JDK11,到底带来了哪些特性呢?值得我们升级吗?而且升级过程会遇到哪些问题呢?带着这些问题,本篇文章将带来完整的JDK8升级JDK11最全实践。

2、为什么升级JDK11

1)性能提升

更好的垃圾收机制、更快的类加载器, 加快应用程序的运行速度。综合评估,从Java 8 升级到 Java 11,G1GC平均速度提升16.1%,ParallelGC为4.5%基于OptaPlanner的用例基准测试表明)

2)特性和改进

局部变类型推断、新的 API、HTTP/2客户端、Lambda表达式的新特性等,这些新特性可以提高开发效率。

3)支持最新的技术和框架

许多新的技术和框架已经或即将开始依赖于JDK11或以上版本,升级后可以保证应用程序能够分利用这些新的技术和框架。

4)长期支持版本

JDK11是Oracle官方发布的一个长期支持(LTS),意味着它将获得长期的更新和支持,有助于保持用程序的稳定性和可靠性。

5)行业趋势

数据来自 New Relic 在2023年1月发布的Java生态报告,从下图可以看出:

  • 目前市面上有 超过 56%的应用程序使用了JDK 11,Java 8 的使用从2020年的84%降低到了现在的32%左右。大部分公司在这三年之间都升级到了JDK 11 或者 JDK 17这两个LTS版本上面。
  • 垃圾收集器使用情况来看,JDK11版本及以上 G1使用率最高,占比高达65%

3、升级后GC效果

先给出结论:

  1. JDK11相对于JDK8,所有垃圾回收器的性能都有提升,特别是大内存机器下G1的提升最明显
  2. 8G内存以下的机器,推荐使用Parallel GC,如果特别追求低延迟,选择牺牲吞吐量,可以使用G1,并设置期望的最大垃圾回收停顿时间来控制
  3. 8G及以上的大内存机器,推荐使用G1 4、不推荐使用CMS,升级后从各项数据来看,CMS收集器都不如G1

我在JDOS平台上选择了不同配置的机器(2C4G、4C8G、8C16G),并分别使用JDK8和JDK11进行部署和压测。

整个压测过程限时60分钟,用180个虚拟用户并发请求一个接口,每次接口请求都创建512Kb的数据。最终产出不同GC回收器的各项指标数据,来分析GC的性能提升效果。

以下是压测的性能情况:

* 上面给出的GC升级效果,采用的是默认的配置,没有做任何优化,只提供参考。真正的GC调优是个技术活,需要根据业务需求、机器配置和实际压测效果等综合评估来选出最合适的GC垃圾回收器。

* 不同垃圾回收器的特点:

  1. Parallel GC - JDK 8及以下版本的默认收集器,关注吞吐量,尝试在最小延迟的情况下尽快完成工作并提高吞吐量。

  2. CMS - 一个老年代收集器,基于标记-清除算法实现,关注延迟,以最短回收停顿时间为目标

  3. Garbage First(G1)- JDK 9以后的默认收集器,G1 关注总体的性能,会尝试在吞吐量和延迟之间做平衡。

4、JDK11带来了哪些新特性

4.1、GC改进

默认垃圾回收器改为G1,废弃CMS垃圾回收器

◦ G1特点:目标是降低应用程序的停顿时间并提高吞吐量。

引入ZGC垃圾回收器(可伸缩低延迟垃圾收集器) 但由于JDK11中ZGC还不够完善,推荐在JDK17中再使用稳定版ZGC

◦ Full GC的停顿不超过10毫秒

◦ 支持TB级堆内存回收

◦ 相对于G1吞吐量下降不超过15%

4.2、模块化

Java9引入了对于模块化软件支持,而Java11进一步扩展了这种特性。模块化让应用程序 更精简,减少对其他类库的依赖和冗余代码,提高运行效率和安全性

然而,目前不推荐使用模块化,因为相关组件生态还不完善,并且模块化带来的价值不够突出。具体原因请看后面章节的详细分析:新特性实践-模块化。

4.3、语法增强

◦ 局部变量推断,引入var局部变量类型,允许开发人员省略通常不必要的局部变量类型初始化声明

◦ Lambda表达式简化,内部可以使用var

接口中可以定义私有方法,可以实现接口方法的访问控制和代码复用

4.4、API增强

HTTPClient标准化支持:强大而灵活的HTTP客户端API,支持多协议(HTTP/2、WebSocket)、异步非阻塞、流操作和连接池等特性。ps:再也不需要用第三包 HttpClient 工具包

字符串方法增强isBlanklinesstripstripLeadingstripTrailingrepeat

Files增强:readString、WriteString

InputStream增强:transferTo(流快速拷贝)

stream增强,dropWhile(从集合中删除满足的)、takeWhile(从集合中获取满足的)、ofNullable

集合工厂方法:Sets.of()、List.of()、Map.of()、Map.ofEntries(),举例:List list = List.of("Java", "Python", "C++");

5、如何升级

5.1、升级应用评估

  • 为保证稳定性,我们优先在新业务新应用来落地实施JDK11的升级。

5.2、JDK选择

自从2019年1月起,Oracle JDK后续的版本开始商用收费,所以推荐大家选择OpenJDK11,OpenJDK和OracleJDK功能上没有差异,支持免费商用。

OpenJDK11下载地址:https://jdk.java.net/archive/

5.3、GC配置

根据自身需求和机器配置选择GC,不同GC的JVM启动参数配置:

  • G1垃圾回收器(JDK11默认,不需要手动配置):-XX:+UseG1GC
  • Parallel GC垃圾回收器:XX:+UseParallelGC

5.4、升级过程踩坑

整个升级过程还是比较简单的,除了升级JDK版本,实际遇到的问题如下:

5.5、升级后验证

升级后完成,做好单测和回归测试,推荐能做个压测验证,防止影响线上服务稳定性

6、新特性实践-模块化

Java一直是构建大型应用程序的主流语言之一。然而随着Java生态系统中存在着大量库和复杂的代码块之间关系难以理清的问题,构建系统变得困难且超出了我们的理解和有效开发的范围。特别是在使用繁多的Java存档文件(Java Archive, JAR)时,这一问题变得更加突出。为了应对这种复杂性,模块化能够很好地管理和减少代码的复杂性。因此自Java9开始,引入了模块化系统。通过模块化,Java本身也得以进行模块化改进。

6.1、模块化是什么?

模块化指的是JAVA平台的模块系统(Java Platform Module System),简称JPMS。JPMS引入一种新方式来组织和构建Java应用程序,它将代码分为相互独立、可复用的模块。每个块都有自己的命名空间,明确声明并控制其他模块的访问权限。这种模块化设计使得开发人员能够更好地维护复杂的应用程序,提高代码的复用性、可维护性和安全性,同时提升应用的加载速度和性能。****最大的特点是可以定义模块描述符来隔离module(Jar包)内部类的访问权限。

模块化的几点关键说明:

1)相对于JDK8的变动

  • JDK9以后引入了一个新组件module:模块描述符module-info.java,用于将一组相关的包放入一个组中。
  • 在Java8和更早的应用程序中,应用程序将包作为顶级组件,Java9以后应用程序将模块作为顶级组件
  • 一个模块(Jar包)只能有一个module-info.java。

2)和maven的关系

模块化并不是要替代maven,和maven本身并不冲突,maven定义jar之间的依赖关系,模块化是对已经依赖的jar下的包进行更细粒度依赖控制

3)如何兼容旧应用

天然兼容旧应用。为了向后兼容旧项目,一些库本身并未模块化,其仍然可以作为模块在模块路径中使用,而这些库在模块路径上时会被转化为自动模块,例如:jackson-databind-1.0.0.jar将成为自动模块jackson.databind

6.2、带来了哪些好处?

1)封装和隔离,更好的访问控制

模块化允许开发者将代码和资源封装在独立的模块中。模块之间可以明确地定义公开和私有的API,提供了更好的代码隔离性和可维护性。

ps:新业务单应用可以按照领域模型来进行多模块的划分,以避免代码腐化。简单举例单应用下存在产品.jar、订单.jar。订单依赖产品,通过模块化的限制,订单只能使用产品中明确对外暴露的类,这样就避免传统模式订单.jar可能依赖了产品.jar中普通的类导致代码腐化的问题,也降低后续领域服务拆分的复杂度

2)更好的可伸缩性,加载速度的提升

模块化系统使得Java平台更加可伸缩,通过模块化定义,可以仅加载需要的模块,从而提升加载类的效率,最终减少了应用程序的内存占用和启动时间,同时打包后的程序也更小。

3)明确的依赖关系

模块化系统要求在模块之间明确定义依赖关系。在编译或运行代码之前,模块系统会检查模块是否满足所有依赖关系,从而导致更少的运行时错误。

4)安全

在JVM的最深层次上执行强封装,减少Java运行时的攻击面,同时无法获得对敏感内部类的反射访问。

6.3、如何使用

1)定义module-a.jar

包结构如下:

com.jdt.a
        person
            Men.java
        reflect
            ReflectModel.java
        module-info.java    




module-info文件内容如下:

module module.a { 
    //指令用于指定一个模块中哪些包下的public对外是可访问的,包括直接引入和反射使用 
    exports com.jdt.a.person; 
    // 只能被反射调用,用于指定某个包下所有的 public 类都只能在运行时可被别的模块进行反射,并且该包下的所有的类及其乘员都可以通过反射进行访问。 
    opens com.jdt.a.refect; 
}




2)定义module-b.jar,包的pom中指定依赖了module-a

包结构如下:

com.jdt.b
        test
            Test.java
        module-info.java    




module-info文件内容如下:

module module.b {
     //依赖a下的包
     requires module.a;
}




3)此时module-b.jar,在编写编码时,会遇到如下问题

6.4、实践过程的坑

上面简单介绍了模块化的知识,具体在落地过程中,我们主要踩了以下的坑,供大家参考

1)依赖JSF包时无法模块化

* JSF是京东内部使用的高性能RPC框架

进行模块化时,pom中依赖了jsf包,模块定义如下:

module module.a {
    requires  fastjson;
    //依赖jsf包名
    requires  jsf.lite;

    exports com.jd.jdk.test.module;
}




此时编译报错如下:提示找不到模块:jsf.lite,但是pom中明明指定依赖了jsf.lite

问题原因:

经过一系列定位研究,发现jsf-lite包中,/META-INF/services下的文件org.glassfish.jersey.internal.spi.AutoDiscoverable里面写的类是com.alibaba.fastjson.support.jaxrs.FastJsonAutoDiscoverable,此类并未在当前jsf.lite包中定义,属于com.alibaba.fastjson包的。

但是我们的pom中明明也依赖了com.alibaba.fastjson包,为什么模块化后,就找不到了呢?

主要原因在于模块化遇到SPI(Service Provider Interface)时的约束:模块化时,SPI机制要求配置中定义依赖的类必须本模块定义的,不能是其他模块的包(来自它不拥有的包),否则,此包将无法被模块化

这样也就解释了,为什么上面jsf无法找到module的问题,jsf-lite里面设置了它不拥有的包:com.alibaba.fastjson.support.jaxrs.FastJsonAutoDiscoverable,导致jsf-lite包无法被自动模块化

解决方案:

1、联系JSF团队,升级JSF包,修复上面说的FastJsonAutoDiscoverable配置错误的问题。

2)拆包问题(模块隔离)

模块化约束:jdk9以上,使用模块化时不支持拆分包的形式依赖

拆分包意味着两个模块包含相同的包,Java模块系统不允许拆分包。拆分包始终是不正常的,而当使用解析可传递依赖项的构建工具(如Maven等)时,很容易出现同一个库的多个版本,当Java模块系统检测到一个包存在于模块路径上的多个模块中时,就会拒绝启动。

例如:

module-a.jar包结构定义:
com.foo.package
    A.java
    
module-b.jar包结构定义:
com.foo.package
    B.java   




当module-c同时依赖module-a和module-b时,如上编译时会报一个错,Package com.foo.package in both module module.b and module module.a,这就是JAVA9的模块隔离,要求只能从一个模块(module)中读取同一个包(package),不能跨模块读取。

解决方案:

如果在使用模块化时,遇到了拆分包问题,无论如何都是无法绕过的。即使从用户角度来看基于类路径的应用程序可以正确工作,你也最终需要处理这些问题。此时只能停用模块化或升级jar包,避免拆分包问题

6.5、模块化落地总结

目前不推荐使用模块化,因为相关组件生态还不完善,并且模块化带来的价值不够突出:

  1. 很多中间件都是基于jdk8构建的,都有可能遇到模块化兼容的问题,比如:jsf,需要jsf强制升级才可以使用模块化

  2. 拆包问题无法解决,比如:aws-java-sdk-s3、fluent等。

7、总结

  1. 升级过程简单,升级后可以使用更多新特性和更好的GC性能,所以 建议升级到JDK11
  2. 现阶段 不推荐使用模块化,但是不用担心会影响JDK11的升级。

另外听说JDK17的 ZGC可以达到亚秒级停顿,但考虑到JDK11的ZGC还不是很稳定,所以本次不做测试,后面升级到JDK17后再给大家分享ZGC压测效果。

希望以上分享可以给大家带来实际的帮助。

作者:京东科技 曲振富

来源:京东云开发者社区 转载请注明来源

与JDK8升级JDK11最全实践干货来了相似的内容:

JDK8升级JDK11最全实践干货来了

截至目前(2023年),Java8发布至今已有9年,2018年9月25日,Oracle发布了Java11,这是Java8之后的首个LTS版本。那么从JDK8到JDK11,到底带来了哪些特性呢?值得我们升级吗?而且升级过程会遇到哪些问题呢?带着这些问题,本篇文章将带来完整的JDK8升级JDK11最全实践。

我有点想用JDK17了

大家好呀,我是summo,JDK版本升级的非常快,现在已经到JDK20了。JDK版本虽多,但应用最广泛的还得是JDK8,正所谓“他发任他发,我用Java8”。 其实我也不太想升级JDK版本,感觉投入高,收益小,不过有一次我看到了一些使用JDK17新语法写的代码,让我改变了对升级JDK的看法,因为这些

从JDK8升级到JDK17

一、概述 鉴于JDK8已经是老古董,还有性能问题,兼且各个公司已经不再维护1.8的JDK,所以升级公司的核心产品之一的后端到JDK到17是相对要紧的事情。 通过升级到jdk17,具有以下好处: 不要在头疼同时适应两个jdk,放下适应JDK8的负担 在生产环境基本上只需要部署一个jdk即可 具有更好的

Spring Boot 3.0横空出世,快来看看是不是该升级了

简介 Spring boot 3.0于2022年11月正式发布了,这次的发布对于我们普通程序员的影响有多少呢?我们是不是需要考虑立马升级到Spring Boot3.0呢? 别急,看完这篇文章再来做决定也不迟。 对JAVA17和JAVA19的支持 相信很多小伙伴到现在还是使用得是JDK8,但是JDK8

[转帖]【JVM】JVM源码分析之Metaspace解密

概述 metaspace,顾名思义,元数据空间,专门用来存元数据的,它是jdk8里特有的数据结构用来替代perm,这块空间很有自己的特点,前段时间公司这块的问题太多了,主要是因为升级了中间件所致,看到大家讨论来讨论去,看得出很多人对metaspace还是模棱两可,不是很了解它,因此我觉得有必要写篇文

轻量灵动: 革新轻量级服务开发

从 JDK 8 升级到 JDK 17 可以让你的应用程序受益于新的功能、性能改进和安全增强。下面是一些 JDK 8 升级到 JDK 17 的最佳实战

JDK 17 营销初体验 —— 亚毫秒停顿 ZGC 落地实践

自 2014 年发布以来, JDK 8 一直都是相当热门的 JDK 版本。其原因就是对底层数据结构、JVM 性能以及开发体验做了重大升级,得到了开发人员的认可。但距离 JDK 8 发布已经过去了 9 年,那么这 9 年的时间,JDK 做了哪些升级?是否有新的重大特性值得我们尝试?能否解决一些我们现在苦恼的问题?带着这份疑问,我们进行了 JDK 版本的调研与尝试。

千呼万唤始出来 JDK 21 LTS, 久等了

平地起惊雷!!! 目录英雄的迟暮大人时代变了JDK 21 LTS 前 JAVA并发编程模型JDK 21 LTS 中的 JAVA 并发编程模型虚拟线程 VS 线程池The Last 你可以称呼它为:JDK 8 之后的神,它也是很多人认为的 JDK 8 之后,最值得升级的版本。 以前大家都说: 他发任他

JDK8到JDK17有哪些吸引人的新特性?

本文主要介绍JDK8到JDk17近200个JEP中比较有价值的新特性(按照价值从高到低排序),这里有一部分特性作者也在线上环境使用过,也会将其中的使用心得分享给大家。

[转帖]JVM-JDK8-G1垃圾收集器相关参数

https://www.cnblogs.com/happyflyingpig/p/15866285.html -XX:+UseG1GC 使用 G1 垃圾收集器 -XX:MaxGCPauseMillis -XX:MaxGCPauseMillis 设置期望达到的最大GC停顿时间指标(会尽力实现,但不保证