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成果
先给出论断：
- JDK11绝对于JDK8，所有垃圾回收器的性能都有晋升，特地是大内存机器下G1的晋升最显著
- 8G内存以下的机器，举荐应用Parallel GC，如果特地谋求低提早，抉择就义吞吐量，能够应用G1，并设置冀望的最大垃圾回收进展工夫来管制
- 8G及以上的大内存机器，举荐应用G1 4、不举荐应用CMS，降级后从各项数据来看，CMS收集器都不如G1
我在JDOS平台上抉择了不同配置的机器（2C4G、4C8G、8C16G），并别离应用JDK8和JDK11进行部署和压测。
整个压测过程限时60分钟，用180个虚构用户并发申请一个接口，每次接口申请都创立512Kb的数据。最终产出不同GC回收器的各项指标数据，来剖析GC的性能晋升成果。
以下是压测的性能状况：
* 下面给出的GC降级成果，采纳的是默认的配置，没有做任何优化，只提供参考。真正的GC调优是个技术活，须要依据业务需要、机器配置和理论压测成果等综合评估来选出最合适的GC垃圾回收器。
* 不同垃圾回收器的特点：
- Parallel GC - JDK 8及以下版本的默认收集器，关注吞吐量，尝试在最小提早的状况下尽快实现工作并进步吞吐量。
- CMS - 一个老年代收集器，基于标记-革除算法实现，关注提早，以最短回收进展工夫为指标
- 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 工具包
◦ 字符串办法加强：isBlank、lines、strip、stripLeading、stripTrailing和repeat
◦ Files加强：readString、WriteString
◦ InputStream加强：transferTo（流疾速拷贝）
◦ stream加强，dropWhile（从汇合中删除满足的）、takeWhile（从汇合中获取满足的）、ofNullable
◦ 汇合工厂办法：Sets.of()、List.of()、Map.of()、Map.ofEntries()，举例：List<String> 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、模块化落地总结
目前不举荐应用模块化，因为相干组件生态还不欠缺，并且模块化带来的价值不够突出：
- 很多中间件都是基于jdk8构建的，都有可能遇到模块化兼容的问题，比方：jsf，须要jsf强制降级才能够应用模块化
- 拆包问题无奈解决，比方：aws-java-sdk-s3、fluent等。
7、总结
- 降级过程简略，降级后能够应用更多新个性和更好的GC性能，所以 倡议降级到JDK11。
- 现阶段 不举荐应用模块化，然而不必放心会影响JDK11的降级。
另外据说JDK17的 ZGC能够达到亚秒级进展，但思考到JDK11的ZGC还不是很稳固，所以本次不做测试，前面降级到JDK17后再给大家分享ZGC压测成果。
心愿以上分享能够给大家带来理论的帮忙。
作者：京东科技 曲振富
起源：京东云开发者社区 转载请注明起源