什么?jdk都到21了,8-17都升级了啥?
jdk都到21了,8-17都升级了啥?
今年jdk已经发布了21版本,我的技术体系还停留在8,不由得开始焦虑。本文我们盘点一下从jdk8到jdk17都更新了哪些技术点。
为什么是jdk17呢?因为jdk17是一个LTS版本,至少到2029年,它都会是jdk8的优秀替代品。
❝JDK 17 最多可以支持到 2029 年 9 月份。按照技术更新迭代的速度,这次免费商用 8 年可谓是良苦用心,为的就是让使用者放心大胆地将 JDK 升级到 JDK 17.
话不多说,开始我们的盘点。
jdk9(2017年9月)
-
模块化 -
提供了List.of()、Set.of()、Map.of()和Map.ofEntries()等工厂方法 -
接口支持私有方法 -
Optional类改进 -
多版本兼容Jar包 -
JShell工具 -
try-with-resources的改进 -
Stream API的改进 -
设置G1为JVM默认垃圾收集器 -
支持http2.0和websocket的API
重要特性:主要是API的优化,如支持HTTP2的Client API、JVM采用G1为默认垃圾收集器。
JDK10(2018年3月)
-
局部变量类型推断,类似JS可以通过var来修饰局部变量,编译之后会推断出值的真实类型 -
不可变集合的改进 -
并行全垃圾回收器 G1,来优化G1的延迟 -
线程本地握手,允许在不执行全局VM安全点的情况下执行线程回调,可以停止单个线程,而不需要停止所有线程或不停止线程 -
Optional新增orElseThrow() -
方法类数据共享 -
Unicode 语言标签扩展 -
根证书
重要特性:通过var关键字实现局部变量类型推断,使Java语言变成弱类型语言、JVM的G1垃圾回收由单线程改成多线程并行处理,降低G1的停顿时间。
JDK11(LTS版本)
-
增加一些字符串处理方法 -
用于 Lambda 参数的局部变量语法 -
Http Client重写,支持HTTP/1.1和HTTP/2 ,也支持 websockets可运行单一Java源码文件,如:java Test.java -
ZGC:可伸缩低延迟垃圾收集器,ZGC可以看做是G1之上更细粒度的内存管理策略。由于内存的不断分配回收会产生大量的内存碎片空间,因此需要整理策略防止内存空间碎片化,在整理期间需要将对于内存引用的线程逻辑暂停,这个过程被称为"Stop the world"。只有当整理完成后,线程逻辑才可以继续运行。(并行回收) -
支持 TLS 1.3 协议 -
Flight Recorder(飞行记录器),基于OS、JVM和JDK的事件产生的数据收集框架 -
对Stream、Optional、集合API进行增强
重要特性:对于JDK9和JDK10的完善,主要是对于Stream、集合等API的增强、新增ZGC垃圾收集器。
JDK12(2019年3月)
-
Switch 表达式扩展,可以有返回值 -
新增NumberFormat对复杂数字的格式化 -
字符串支持transform、indent操作 -
新增方法Files.mismatch(Path, Path) -
Teeing Collector -
支持unicode 11 -
Shenandoah GC,新增的GC算法 -
G1收集器的优化,将GC的垃圾分为强制部分和可选部分,强制部分会被回收,可选部分可能不会被回收,提高GC的效率
重要特性:switch表达式语法扩展、G1收集器优化、新增Shenandoah GC垃圾回收算法。
JDK13(2019年9月)
-
Switch 表达式扩展,switch表达式增加yield关键字用于返回结果,作用类似于return,如果没有返回结果则使用break -
文本块升级 """ ,引入了文本块,可以使用"""三个双引号表示文本块,文本块内部就不需要使用换行的转义字符 -
SocketAPI 重构,Socket的底层实现优化,引入了NIO -
FileSystems.newFileSystem新方法 -
ZGC优化,增强 ZGC 释放未使用内存,将标记长时间空闲的堆内存空间返还给操作系统,保证堆大小不会小于配置的最小堆内存大小,如果堆最大和最小内存大小设置一样,则不会释放内存还给操作系统
重要特性:ZGC优化,释放内存还给操作系统、socket底层实现引入NIO。
JDK14(2020年3月)
-
instanceof模式匹配,instanceof类型匹配语法简化,可以直接给对象赋值,如if(obj instanceof String str),如果obj是字符串类型则直接赋值给了str变量 -
引入Record类型,类似于Lombok 的@Data注解,可以向Lombok一样自动生成构造器、equals、getter等方法; -
Switch 表达式-标准化 -
改进 NullPointerExceptions提示信息,打印具体哪个方法抛的空指针异常,避免同一行代码多个函数调用时无法判断具体是哪个函数抛异常的困扰,方便异常排查; -
删除 CMS 垃圾回收器
重要特性:引入了Pattern Matching for instanceof、Records等重要特性。完全移除了CMS回收器。
JDK15(2020年9月)
-
EdDSA 数字签名算法 -
Sealed Classes(封闭类,预览),通过sealed关键字修饰抽象类限定只允许指定的子类才可以实现或继承抽象类,避免抽象类被滥用 -
Hidden Classes(隐藏类) -
移除 Nashorn JavaScript引擎 -
改进java.net.DatagramSocket 和 java.net.MulticastSocket底层实现
重要特性:引入了Sealed类、隐藏类、并行垃圾收集等重要特性。
JDK16(2021年3月)
-
允许在 JDK C ++源代码中使用 C ++ 14功能 -
ZGC性能优化,去掉ZGC线程堆栈处理从安全点到并发阶段 -
增加 Unix 域套接字通道 -
弹性元空间能力 -
提供用于打包独立 Java 应用程序的 jpackage 工具
重要特性:引入了记录类、垃圾回收器接口、Unix域套接字通道等重要特性。
❝JDK16相当于是将JDK14、JDK15的一些特性进行了正式引入,如instanceof模式匹配(Pattern matching)、record的引入等最终到JDK16变成了final版本。
JDK17(2021年9月)(LTS版本)
-
Free Java License -
JDK 17 将取代 JDK 11 成为下一个长期支持版本 -
Spring 6 和 Spring Boot 3需要JDK17 -
移除实验性的 AOT 和 JIT 编译器 -
恢复始终执行严格模式 (Always-Strict) 的浮点定义 -
正式引入密封类sealed class,限制抽象类的实现 -
统一日志异步刷新,先将日志写入缓存,然后再异步刷新
重要特性:虽然JDK17也是一个LTS版本,但是并没有像JDK8和JDK11一样引入比较突出的特性,主要是对前几个版本的整合和完善。
一点感想
学技术时间长了难免就麻木了,归根到底还是因为没有面对复杂、棘手的问题,倒逼你更新只是体系。
生产中,能用就会凑乎用,实在没办法才会升级,深有体会。
每次技术的革新都是业务倒逼的,当然也会去主动看一些技术,但是没有落地的技术就是虚的。
我们最近在做jdk版本升级,这些点可能是值得考虑升级的出发点:
-
更好的并发性能:JDK 17引入了Project Loom,它引入了一种轻量级的并发模型,称为协程。协程能够提供更高效的并发处理能力,允许应用程序创建更多的并发任务而不会消耗过多的系统资源。这将带来更好的性能和吞吐量,特别是在处理高并发任务时。
-
更快的应用程序启动:JDK 17中的Project Loom还可以实现更快的应用程序启动速度。传统的线程模型需要更多的时间和资源来启动新线程,而协程的启动速度几乎可以立即完成。这意味着应用程序可以更快地响应用户请求,提供更好的用户体验。
-
更少的上下文切换开销:在传统的线程模型中,线程之间的切换需要操作系统的干预,涉及到保存和恢复线程的上下文信息,这会产生一定的开销。而协程之间的切换不需要操作系统的干预,因此上下文切换的成本非常低。这将减少不必要的开销,提高应用程序的性能和响应速度。
-
更简单的编程模型:协程提供了更直观且易于编写和维护的代码模型。开发者可以使用同步的方式编写并发代码,而不需要显式地处理线程和锁。这将减少开发人员的工作量,降低编写并发代码的复杂性,并减少出错的可能性。
JDK的升级是业务发展的必然趋势。相当数量的开发者觉得觉得升级是一种负担,会造成额外工作,出了问题费力不讨好,要是出了安全问题更是麻烦。
但是话说回来,从企业角度说节省成本很重要,商业版jdk收费很高,jdk17是目前免费且稳定性很好的一个版本。
技术上,Spring也不再维护过去的版本,想要用新特性,就不得不换版本。更新技术,必然会助推JDK的升级。当越来越多的公司都更新到JDK17,更多的框架新版本都会最低支持JDK17,因为兼容旧JDK成本实在太高,当框架、论坛都是讨论JDK17的技术和各种解决问题的方法时,必然会反推企业进行升级。
对我们个人而言,不断更新技术体系,让自己不被淘汰,基本是正确的选择。
PS: 大概率在jdk21版本,Project loom会正式推出,并且已知JDK21又是一个长期支持版本 (LTS) ,值得期待。
loom(协程)一旦release,各种servlet容器,框架如jetty,netty,vert.x等,在它们最新版本基本都会支持loom,或者叫做虚拟线程的支持, 可以预见一旦JDK21发行,很多软件都会迎来一波大迭代更新。
为了当loom来临的时刻,各种框架版本井喷的时候不被淘汰,JDK17赶紧学起来,用起来吧。