科普文：软件架构JDK系列之【JDK8、11、17选型】

概叙

科普文：软件架构JDK系列之【JDK8语言特性】-CSDN博客

科普文：软件架构JDK系列之【JDK11语言特性】-CSDN博客

科普文：软件架构JDK系列之【JDK17语言特性】-CSDN博客

科普文：如何选择jdk和jdk版本_openjdk发行版选择-CSDN博客

科普文：主流JDK性能大比拼；Zulu OpenJDK/OpenJDK/Oracle JDK/GraalVM CE-CSDN博客

科普文：Oracle JDK收费后的常见openJDK版本梳理-CSDN博客

科普文：【方向盘】OpenJDK生态圈_jdk8u211-CSDN博客

Java是一门广泛使用的编程语言，拥有着丰富的生态系统和大量的开发者。

Java的官方实现是Oracle公司的JDK（Java Development Kit），目前最新版本是JDK 21，而JDK 8是一个长期支持版本（LTS）。

JDK 8于2014年发布，引入了许多重要的新特性，如Lambda表达式、Stream API和新的日期时间API等。而JDK 17于2021年发布，对性能、安全性和语言特性等方面都有所提升和改进。

JDK为什么升级？

目前大多数应用用的还是JDK 8，不知道高版本的JDK能带来什么收益，所以没有动力去升级，我理解升级JDK版本带来的收益核心有三点：

1. 性能收益，从已升级的应用的数据来看，性能收益还是不错的，后面详细介绍

2. 新特性， 高版本有更多的语法和功能供我们使用

3. 业界主流趋势 springboot 、netty、Kafka这些常用的框架在高版本里已不再支持低版本JDK(JDK8及以下）

JDK的升级是必然趋势

不升级的人说，目前来说国内很多程序猿可能觉得升级会造成额外工作，出了问题费力不讨好，要是出了安全问题，更要提桶跑路。

也有说没有实质性的好处，而且还有风险，还有从企业角度说，未来也不升级，因为去Oracle化。但考虑到未来oracle不再维护JDK8，Spring也不再维护过去版本的时候，为了跟上时代，使用最新技术，必然会助推JDK的升级。
当越来越多的公司加入到JDK17以上的大军中，未来更多的框架新版本都会最低支持JDK17，因为兼容旧JDK实在不值得，当大部分框架和社区、论坛都是讨论JDK17的技术和各种解决问题的方法时，必然会反推企业进行升级。

如何选择JDK版本？

首选 LTS版本， JDK 8以后LTS版本目前就两个，JDK 11和 JDK17, 对应集团内的版本就是AJDK 11和 AJDK 17, 直接从JDK 8 -> JDK 17, 风险较高，由于没有经过JDK 11过渡，可能会出现测试未覆盖代码在线上运行时直接异常退出情况。

总的来看，目前选择JDK11是一个不错的选择，建议大家可以先升级JDK11, 如果有需求再升级JDK17， 如果有的同学对应用的代码和依赖完全可控， 可以直接升JDK 17。

另外附上New Relic 2022年3月发布的一份 Java 生态系统状况报告[1] 供参考，该报告基于从数百万个提供性能数据的匿名应用程序中收集的数据。报告显示，JDK 11 采用率已经超过 JDK 8，已经成为生产环境的最新标准。

1.从JDK8到JDK17，Java在语法、API、性能、安全性和开发工具等方面都进行了大量的改进和增强，为Java开发人员提供了更加丰富和强大的编程能力。

2.JDK 17是一个功能丰富的Java版本，它带来了性能提升、安全性增强、更好的开发体验和面向未来的技术特性。通过使用这些新特性，开发人员可以编写更高效、更安全、更易于维护的Java应用程序。

3.Spring带头猛冲，直接上JDK17。如果Spring6还支持Java8的话，那很多技术框架都要跟着Java8的兼容，与其这样不如由Spring带头，一起飞升Java17，不过有些框架还不支持JDK17

4.性能升级，光从java8换到java11，啥也没干性能直接就提升了10%（nio底层的重写），更何况一路到jdk17过程中的JVM相关优化。 不过光是性能的优化还不足以吸引企业进行JDK升级，毕竟加机器就能解决，费不着各种升级改造，还可能有安全问题

5.JDK21可能成为真正的经典版本。目前还没有Project loom功能，代表着没有协程，性能方面比有协程jdk差远了。比如阿里开源的jdk8,11,就有非侵入式协程，这方面比JDK17强。

从发展趋势看，Project loom功能在JDK19已经可预览了，可以发现该版本许多的java工具都开始针对loom进行升级，Project loom大概在JDK21进行正式推出，而JDK21又是一个长期支持版本 (LTS) ，值得期待。

各种servlet容器，还有jetty，netty，vert.x等，在它们最新版本的release note找到对应的升级标注，说，我们添加了某某支持，其中最重要的就是loom，或者叫做虚拟线程的支持, 可以预见一旦JDK21发行，很多软件都会跟上投入生产！

为什么升级JDK17? 或者为什么选择JDK17？

1）长期支持版本

JDK17是Oracle官方在2021年9月14日发布的一个长期支持（LTS）版本，意味着它将获得长期的更新和支持，有助于保持程序的稳定性和可靠性。

2）性能提升

更好的垃圾回收器。综合评估，从Java 8 升级到 Java 11，G1GC平均速度提升16.1%，ParallelGC为4.5%，从Java 11 升级到 Java 17，G1GC平均速度提升8.66%，ParallelGC为6.54%（基于OptaPlanner的用例基准测试表明）

最大的亮点是带来了稳定版的ZGC垃圾回收器，达到亚毫秒级停顿。

3）新语法和特性

Switch表达式简化、Text Blocks文本块、instanceof 的模式匹配升级和NullPointerException提示信息改进等

4）支持最新的技术和框架

Spring framework6 和Spring Boot3 都默认使用 Java 17作为最低版本

5）GC变化

JDK9: 设置G1为JVM默认垃圾收集器

JDK10：并行全垃圾回收器 G1，通过并行Full GC, 改善G1的延迟。目前对G1的full GC的实现采用了单线程-清除-压缩算法。JDK10开始使用并行化-清除-压缩算法。

JDK11：推出ZGC新一代垃圾回收器（实验性）,目标是GC暂停时间不会超过10ms，既能处理几百兆的小堆，也能处理几个T的大堆。

JDK14 ：删除CMS垃圾回收器;弃用 ParallelScavenge + SerialOld GC 的垃圾回收算法组合;将 zgc 垃圾回收器移植到 macOS 和 windows 平台

JDk 15 : ZGC (JEP 377) 和Shenandoah (JEP 379) 不再是实验性功能。默认的 GC 仍然是G1。

JDK16：增强ZGC，ZGC获得了 46个增强功能 和25个错误修复，控制stw时间不超过10毫秒

6）升级后压测效果

先给出结论： 1、JDK17相对于JDK8和JDK11，所有垃圾回收器的性能都有很明显的提升，特别是稳定版的ZGC垃圾回收器 2、不论任何机器配置下，都推荐使用ZGC，ZGC的停顿时间达到亚毫秒级，吞吐量也比较高

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

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

以下是压测的性能情况：

7）指标测试

1.吞吐量比较

在吞吐量方面，Parallel 中 JDK 8 和 JDK 11 差距不大，JDK 17 相较 JDK 8 提升 15% 左右；G1 中 JDK 17 比 JDK 8 提升 18%；ZGC 在 JDK 11引入，JDK 17 对比JDK 11 提升超过 20%。

2.延迟比较

在 GC 延迟方面，JDK 17 的提升更为明显。我们可以看到为缩短 GC 暂停时间所做的努力都得到了回报,很多提升都是因为 GC 的改进。

在 Parallel 中 JDK 17 对比 JDK 8 和JDK 11 提升 40%；在 G1 中，JDK 11 对比 JDK 8 提升 26%，JDK 17 对比 JDK 8 提升接近 60%！ZGC 中 JDK 17 对比 JDK 11 提升超过 40%。

3.STW暂停时间对比

我们可以看到JDK 17 中的 ZGC 远低于目标：亚毫秒级的暂停时间。G1 的目标是在延迟和吞吐量之间保持平衡，远低于其默认的目标：200 毫秒的暂停时间。ZGC 的设计会保证暂停时间不随堆的大小而改变，我们可以清楚地看到当堆扩大到 128GB 时的情况。从暂停时间的角度来看，G1比Parallel 更善于处理更大的堆，因为它能够保证暂停时间满足特定目标。

4.内存资源占用

上图比较了三个不同收集器原生内存的使用峰值。由于从这个角度来看 Parallel 和 ZGC 都非常稳定，因此我们应该看一看原始数字。我们可以看到 G1 在这方面确实有所改进，主要原因是所有功能和增强功能都提高了记忆集管理的效率 。

总结：无论使用哪种收集器，与旧版本相比，JDK17 的整体性能都有很大的提升。在 JDK 8 中，Parallel是默认设置，但在 JDK 9 中改为了 G1。从那以后，G1 的改进速度就超过了 Parallel，但在有些情况下可能 Parallel 仍然是最佳选择。而 ZGC（JDK 15 正式使用）的加入，成为了第三种高性能替代方案。