Spring Framework6 和 Spring Boot3 是一个跨越式的升级整个框架支持的最低 JDK 版本直接跨越到 JDK17,无论框架层还是基础设施层都做了巨大的改变,Spring 6.0 新框架具体做了哪些功能的升级与改进,是否有必要升级与使用呢?可以继续看一看。
下面可以先看下翻译自 Spring 官方社区一个宣导博客
尊敬的 Spring 社区:我很高兴地宣布,现在 MavenCentral 已经可以提供 SpringFramework6.0.0 了!这是 2023 年及以后新一代框架的开始,包括 OpenJDK 和 Java 生态系统中当前和未来的创新。同时,我们将其精心设计为从 Spring Framework 5.3.x 直接升级到现代运行时环境。作为核心框架的一个主要修订,Spring framework 6.0 附带了 Java 17+基线和 Jakarta EE 9+(在 Jakarta 命名空间中),重点是最近发布的 Jakarta EE10 API,如 Servlet 6.0 和 JPA 3.1。这提供了对最新 web 容器(如 Tomcat 10.1)和最新持久性提供程序(如 Hibernate ORM 6.1)的访问。不要拘泥于 JavaEE8,跳到 jakarta 命名空间,最好直接跳到 JakartaEE10 级别!即将发布的 SpringBoot3.0.0 版本为您提供了相应的托管依赖项。基础架构方面,6.0 为提前转换和相应的 AOT 处理支持 Spring 应用程序上下文提供了基础。这使得 Spring Boot 3 能够为 GraalVM 本地映像提供一流的支持。您还可以探索 Project Loom 的虚拟线程和 Spring 应用程序-请参阅“拥抱虚拟线程”-并深入了解 Project CRaC 的检查点恢复方法,以加快 JVM 启动速度,这两个功能目前都在预览中,但预计将成为基于 SpringFramework6.x 的应用程序的一流功能。Spring Framework 6.0 中还有许多其他特性和改进,例如 HTTP 接口客户端、对 RFC 7807 问题细节的支持,以及 HTTP 客户端基于千分尺的可观察性。请查看我们的“新增内容”页面,了解全面概述,并尽早尝试 6.0.0!2022 年 11 月 16 日 Cheers,Juergen
如果对原文感兴趣也可以直接访问官方原文spring.io/blog/2022/1…
通过官方宣导内容可以看到 Spring 做了很多基础设施方面的改进:
对于主要用于 CRUD 的我们可能仅仅因为这些功能的改变还不值得我们全面升级。下面就整体从 Spring 支持的历史版本来看下。
此时,官方建议尽可能从 MavenCentral 升级到最新的 SpringFramework6.0.x 版本。
根据官方文档的说明 Spring 与 JDK 的兼容版本如下列表所示:
可以看到 5.3.x 及以下的版本都是兼容 JDK8 的, 如果短期内还没有完全计划升级 JDK17 可以使用 5.3.x 的版本不仅仅兼容 JDK8 也会兼容 11 和 17 这两个稳定版本。
有了历史背景接下来直接进去主题,Spring Framework 6.x 的新增了哪些功能?
整体来看 Spring6 做了很多升级,接下来就总结几个比较重要的点:
最低 JDK 支持版本改为 JDK17,可能大家用惯了 JDK8,这个免费又稳定支持的版本,其实 JDK 社区已经发布了支持 G1 垃圾回收器的稳定版本 JDK11,JDK11 就像是一个过渡版本一样,和 JDK8 社区提供支持的时间差不多,另外升级 JDK11 又需要做大量的兼容性测试才能正式使用,倒不如直接使用 JDK17 来的痛快。
JDK17 引入了 ZGC,在 GC 延迟方面,JDK 17 的提升更为明显。根据网上有人压测的数据,在 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%。如果对 GC 延迟有更高的要求的用户可以考虑尽早体验 JDK17。
JDK 17 是一个 Oracle 官宣可以免费商用的 LTS 版本,所谓 LTS,是 Long Term Support,也就是官方保证会长期支持的版本,根据官方数据最多可以支持到 2029 年 9 月份。
可能很多人听说过 JIT,第一次听说 AOT 这个名词,下面就来解释一下:
这两种编译方式的主要区别在于是否在“运行时”进行编译,JIT,即 Just-in-time,动态(即时)编译,边运行边编译;
AOT,Ahead Of Time,指运行前编译,是两种程序的编译方式。
有两种编译 Java 应用程序的方法:使用即时编译 (JIT) 或提前编译 (AOT)。第一种是默认模式,Java Hotspot 虚拟机使用它在运行时将字节码转换为机器码。后者由新颖的 GraalVM 编译器支持,并允许在构建时将字节码直接静态编译为机器码。
JIT (Just-In-Time - 实时编译)
在程序运行时,根据算法计算出热点代码,然后进行 JIT 实时编译,这种方式吞吐量高,有运行时性能加成,可以跑得更快,并可以做到动态生成代码等,但是相对启动速度较慢,并需要一定时间和调用频率才能触发 JIT 的分层机制。JIT 缺点就是编译需要占用运行时资源,会导致进程卡顿。
AOT (Ahead-Of-Time - 预先编译)
AOT 编译能直接将源代码转化为机器码,内存占用低,启动速度快,可以无需 runtime 运行,直接将 runtime 静态链接至最终的程序中,但是无运行时性能加成,不能根据程序运行情况做进一步的优化,AOT 缺点就是在程序运行前编译会使程序安装的时间增加。
现在正处于云原生,降本增效的时代,Java 相比于 Go、Rust 等其他编程语言非常大的弊端就是启动编译和启动进程非常慢,这对于根据实时计算资源,弹性扩缩容的云原生技术相冲突,Spring6 借助 AOT 技术在运行时内存占用低,启动速度快,逐渐的来满足 Java 在云原生时代的需求,对于大规模使用 Java 应用的商业公司可以考虑尽早调研使用 JDK17,通过云原生技术为公司实现降本增效。
关于 AOT 再简单介绍一下 Native Image 这个名词
Native Image 是一项创新技术,可将 Java 代码编译成独立的本机可执行文件或本机共享库。在构建本机可执行文件期间处理的 Java 字节码包括所有应用程序类、依赖项、第三方依赖库和任何所需的 JDK 类。生成的自包含本机可执行文件特定于不需要 JVM 的每个单独的操作系统和机器体系结构。
前面说到了 Spring6 支持的 AOT 技术,这个 Graalvm 就是底层的支持,Spring 也对 GraalVM 本机映像提供了一流的支持。
GraalVM 是一种高性能 JDK,旨在加速用 Java 和其他 JVM 语言编写的应用程序的执行,同时还为 JavaScript、Python 和许多其他流行语言提供运行时。 GraalVM 提供两种运行 Java 应用程序的方法:在 HotSpot JVM 上使用 Graal 即时 (JIT) 编译器或作为提前 (AOT) 编译的本机可执行文件。 GraalVM 的多语言能力使得在单个应用程序中混合多种编程语言成为可能,同时消除了外语调用成本。
GraalVM 向 HotSpot Java 虚拟机添加了一个用 Java 编写的高级即时 (JIT) 优化编译器。
Graalvm 架构如下图所示:
GraalVM 具有以下特性:
总的来说对云原生的要求不算高短期内可以继续使用 2.7.X 的版本和 JDK8,不过 Spring 官方已经对 Spring6 进行了正式版发布,后续有足够精力支持的时候可以尝试在 Spring6 和 JDK17 上进行项目验证尽早升级到这些版本上进行试点比较好。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。