Jdk8-21重要特性总结

官方地址：
https://www.oracle.com/java/technologies/java-se-support-roadmap.html

从上图可以很清晰得可以看出，JDK8,JDK11,JDK17,JDK21是长期维护的版本。
从目前来看，JDK8到2023年已经有将近10年的历史了，大多数依据JDK8的相关技术内容已经很成熟了，但是大家也看到，JDK在不断地迭代，JDK有很多的新特性，而且能够对开发及系统性能有很大帮助。
所以现在很多公司在建新系统的时候，在考虑新的JDK。再加上重要的一点是新的Spring 6 和 spring boot3及对应的spring cloud 2022.X及以上版本，最低支持的JDK也需要JDK17了。
所以要想跟上技术迭代，还需我们自己对于JDK进行了解，然后根据自己的实际选择相应的版本。

版本与特性

JDK8新特性（2014年初）（LTS版本）

• 重要特性：Lambda表达式、函数式接口、方法引用、Stream流式API、JVM采用MetaSpace代替了永久代（PermGen Space）

---

JDK9新特性（2017年9月）

• 重要特性：主要是API的优化（延迟评估），支持HTTP2的Client API、JVM采用G1为默认垃圾收集器

---

JDK10新特性（2018年3月）

• 重要特性：通过var关键字实现局部变量类型推断，使Java语言变成弱类型语言、JVM的G1垃圾回收由单线程改成多线程并行处理，降低G1的停顿时间

---

JDK11新特性（2018年9月）（LTS版本）

• 重要特性：对于JDK9和JDK10的完善，主要是对于Stream、集合等API的增强、新增ZGC垃圾收集器

 ZGC可以看做是G1之上更细粒度的内存管理策略。由于内存的不断分配回收会产生大量的内存碎片空间，因此需要整理策略防止内存空间碎片化，
 在整理期间需要将对于内存引用的线程逻辑暂停，这个过程被称为"Stop the world"。只有当整理完成后，线程逻辑才可以继续运行。（并行回收）

---

JDK12新特性（2019年3月）

• 重要特性：switch表达式语法扩展、G1收集器优化、新增Shenandoah GC垃圾回收算法(OpenJDK 解决之前各种垃圾回收器处理大堆时停顿较长的问题)

将GC的垃圾分为强制部分和可选部分，强制部分会被回收，可选部分可能不会被回收，提高GC的效率

---

JDK13新特性（2019年9月）

• 重要特性：ZGC优化，释放内存还给操作系统、socket底层实现引入NIO

将标记长时间空闲的堆内存空间返还给操作系统，保证堆大小不会小于配置的最小堆内存大小，如果堆最大和最小内存大小设置一样，则不会释放内存还给操作系统；

---

JDK14新特性（2020年3月）

1. instanceof类型匹配语法简化，可以直接给对象赋值，如if(obj instanceof String str),如果obj是字符串类型则直接赋值给了str变量；
2. 引入record类，类似于枚举类型，可以向Lombok一样自动生成构造器、equals、getter等方法；
3. NullPointerException打印优化，打印具体哪个方法抛的空指针异常，避免同一行代码多个函数调用时无法判断具体是哪个函数抛异常的困扰，方便异常排查；

---

JDK15新特性（2020年9月）

密封类 sealed class，通过sealed关键字修饰抽象类限定只允许指定的子类才可以实现或继承抽象类，避免抽象类被滥用；

---

JDK16新特性（2021年3月）

1. ZGC性能优化
2. instanceof模式匹配
3. record的引入
   JDK16相当于是将JDK14、JDK15的一些特性进行了正式引入

---

JDK17新特性（2021年9月）（LTS版本）

1. 正式引入密封类sealed class，限制抽象类的实现；
2. 统一日志异步刷新，先将日志写入缓存，然后再异步刷新；

• 虽然JDK17也是一个LTS版本，但是并没有像JDK8和JDK11一样引入比较突出的特性，主要是对前几个版本的整合和完善。

---

JDK21（2023年9月）（LTS版本）

• 重要特性：序列集合、分代 ZGC、记录模式、switch 模式匹配、虚拟线程、弃用 Windows 32 位 x86 移植、准备禁止动态加载代理、密钥封装机制 API(一种通过公钥密码学安全封装对称密钥的加密技术)

---

补充：

1. Java9 模块化后，不允许应用程序查看来自 JDK 的所有类，会影响部分反射的运行，需要通过以下命令解决

  --add-opens java.base/java.time=ALL-UNNAMED
  --add-opens java.base/java.lang.reflect=ALL-UNNAMED
  --add-opens java.base/java.lang=ALL-UNNAMED
  --add-opens java.base/java.math=ALL-UNNAMED
  --add-exports java.desktop/sun.font=ALL-UNNAMED

---

2. GraalVM

提供了即时编译（JIT）和提前编译（AOT）的支持，以实现更快的启动时间。
(1)提高性能
(2)简化开发
(3)降低成本
(4)节省资源
(5)支持云环境

---

3. GC变化

JDK 9：设置 G1 为 JVM 默认垃圾收集器

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

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

JDK 14 ：删除 CMS 垃圾回收器；弃用 ParallelScavenge + SerialOld GC 的垃圾回收算法组合；将 ZGC垃圾回收器移植到 macOS 和 Windows 平台

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

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

JDK 21:分代 ZGC,JDK21中对 ZGC 进行了功能扩展，增加了分代功能，比如 CMS 收集器区分老年代和年轻代，这样一来，可以更频繁的回收年轻代。

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