隨著 Spring Framework 6.1 和 Spring Boot 3.2 普遍可用性的臨近，我們想分享一下 Spring 團隊為讓開發(fā)人員優(yōu)化其應用程序的運行時效率而做出的幾項努力的概述。

我們將介紹以下技術和用例：

• Spring MVC 將使用 基于JDK 21 虛擬線程 Web 堆棧
• 使用 Spring 和 GraalVM Native Image 優(yōu)化容器部署
• JVM 檢查點恢復：使用 Spring 和 Project CRaC 擴展到零
• 通過 Spring AOT 和 Leyden 項目一睹 OpenJDK 的未來

1、Spring MVC 將使用 基于JDK 21 虛擬線程 Web 堆棧
虛擬線程（Virtual Threads）旨在降低以簡單、流行的每請求線程方式編寫的服務器應用程序的成本，以接近最佳的硬件利用率進行擴展。

虛擬線程降低了 I/O 阻塞的成本，因此非常適合 Servlet 棧上的 Spring Web MVC 應用程序。通過虛擬線程設置，Spring MVC 可以在 Tomcat 或 Jetty 等平臺上充分利用這些新的運行時特性。在大多數(shù)用例中，這不需要修改代碼，就能自然地提供最佳性能，而無需對線程池配置進行微調(diào)。

在 Spring Framework 6.1 中引入一個名為 RestClient 的 "虛擬線程友好型現(xiàn)代 HTTP 客戶端"（Spring Cloud Gateway 和 Spring 產(chǎn)品組合中的相關基礎架構(gòu)同樣可以從虛擬線程設置和 Spring MVC 中受益，從而提供一致的整體體驗。

那么，這對 WebFlux 和反應堆棧意味著什么呢？
我們特意選擇了不同的阻塞堆棧和反應堆棧，以充分利用 WebFlux 服務器中的反應優(yōu)勢，并盡可能精簡 Spring Web MVC 堆棧（start.spring.io 上迄今為止最常用的 Web 堆棧）和常規(guī)阻塞線程架構(gòu)。

• Servlet 容器上的 Spring MVC 是虛擬線程的理想定位，是提高傳統(tǒng)網(wǎng)絡應用程序可擴展性的理想解決方案。
• 另一方面，WebFlux 服務器提供了優(yōu)化的反應式堆棧，非常適合 Netty I/O 設置，通過不同的編程模型提供同等的運行時優(yōu)勢。

當您需要應用級并發(fā)（例如，發(fā)送多個遠程 HTTP 請求（可能是流式請求）并合并結(jié)果）時：

• WebFlux 和 Reactor 等反應式 API 目前具有無可比擬的附加值，
• Kotlin 的 Coroutines 及其 Flow 類型也具有無可比擬的附加值，它們提供了命令式和聲明式編程模型的有趣組合。
• RSocket 是反應式交互模型帶來巨大附加值的另一個例子。

請注意， Spring MVC 也提供可選的反應式支持。

因此，如果您只需要在服務器應用程序中的幾個用例中處理并發(fā)性問題，您可以簡單地使用帶有虛擬線程設置的 Spring MVC 堆棧，并在 Web 控制器中無縫地包含反應式 WebClient 交互，Spring MVC 會將反應式返回值調(diào)整為 Servlet 異步響應。

Spring MVC 中的這種反應式支持完全是可選的，只有在實際使用反應式端點時才需要在堆棧中使用 Reactor 和 Reactive Streams，而且 HTTP 堆棧要基于 Servlet 容器，如 Tomcat 或 Jetty（而不是 Netty）。

對于典型的網(wǎng)絡Web場景，我們預計虛擬線程將成為 Spring MVC 的常見選擇，成為 Java 21+ 的 Spring 開發(fā)人員的Web服務器棧。

請確保使用 Spring Boot 3.2 或更高版本，將屬性 spring.threads.virtual.enable 設置為 true，并使用最新的庫和驅(qū)動程序版本來評估虛擬線程。

2、使用 Spring 和 GraalVM 原生鏡像優(yōu)化容器部署
我們將繼續(xù)完善 Spring Boot 3 中引入的 GraalVM 本機支持。主要用例是使用 Buildpacks 構(gòu)建優(yōu)化的容器映像，其中包含一個微小的操作系統(tǒng)基礎層，以及通過 Spring AOT（Ahead Of Time）轉(zhuǎn)換和 GraalVM 本地映像編譯器編譯為本地可執(zhí)行文件的應用程序。無需分發(fā) JVM。

這樣就可以部署在幾十毫秒內(nèi)啟動的小型容器（通常比普通 JVM 的啟動時間快 50 倍），降低應用基礎架構(gòu)的內(nèi)存消耗，并立即實現(xiàn)峰值性能。

GraalVM 緊跟 Java 的新特性，例如已經(jīng)提供了一流的虛擬線程支持：請參閱 Josh Long 最近發(fā)表的博文《?All together now》。

與 JVM 相比，GraalVM 的出色運行特性得益于不同的權衡取舍。本地鏡像編譯需要幾分鐘而不是幾秒鐘。它需要額外的元數(shù)據(jù)才能正確處理反射、代理和 JVM 的其他動態(tài)行為。Spring 會推斷出很多此類元數(shù)據(jù)，但任何實際項目都可能需要一些額外的提示才能正常運行（例如，對于組織依賴關系）。最后，Spring AOT 轉(zhuǎn)換和 GraalVM 原生鏡像的結(jié)合要求我們在構(gòu)建時凍結(jié)類路徑和 Spring Boot Bean 條件。您通?？梢栽谶\行時配置中更改數(shù)據(jù)庫的 URL 或密碼，但不能更改數(shù)據(jù)庫類型或更改 Spring Bean 的結(jié)構(gòu)。

從歷史上看，另一個缺點是由于缺乏即時編譯而導致峰值性能有限。

有了即時啟動和立即可用的峰值性能，Spring Boot 本機應用程序就能實現(xiàn)零擴展。

縮放為零
縮放為零是對無服務器的一種概括。工作負載不僅可以部署到無服務器云平臺，還可以部署到任何提供在沒有請求要處理時向零擴展能力的 Kubernetes 或云平臺。通過 Kubernetes，您可以使用 Knative 或 KEDA 等解決方案來實現(xiàn)零擴展。

而且，你并不局限于函數(shù)，你可以將任何類型的應用程序、任何類型的編程模型（包括傳統(tǒng)的網(wǎng)絡應用程序）擴展到零。無服務器最重要的特點不在于技術，而在于它所實現(xiàn)的 "即用即付 "計費模式。

在各種用例中，擴展到零可能會很有趣。JVM 在開發(fā)大流量網(wǎng)站方面表現(xiàn)出色，但老實說，我們也開發(fā)了許多小型后臺應用程序，這些應用程序通常不會一直使用。既然沒人使用，我們?yōu)槭裁催€要付費呢？還有一些暫存環(huán)境，它們通常只需要運行一小部分時間，還有一些微服務，緩存允許在大部分時間關閉其中的幾個。還有高可用性，它迫使我們?yōu)槊總€服務維護兩個實例，以備不時之需，因為我們的應用程序啟動時間太長，無法從危險中恢復。

但是，對于那些無法接受 GraalVM 原生鏡像所要求的權衡的項目來說，如何將其擴展為零呢？

3、JVM 檢查點恢復：利用 Spring 和 CRaC 項目實現(xiàn)零擴展
CRaC 是一個 OpenJDK 項目，它定義了一個新的 Java API，允許您在 HotSpot JVM 上檢查點和還原應用程序，該項目由 Azul Systems 開發(fā)，同時也得到 AWS Lambda 和 IBM OpenLiberty 的支持。它基于在 Linux 上實現(xiàn)檢查點/還原功能的 CRIU 項目。

其原理如下：您幾乎像往常一樣啟動應用程序，但使用的是啟用了 CRaC 的 JDK 版本。然后在某個時間點，可能是在執(zhí)行了所有常用代碼路徑而導致 JVM 發(fā)熱的某些工作負載之后，使用 API 調(diào)用、jcmd 命令、HTTP 端點或其他機制觸發(fā)檢查點。

然后，運行中的 JVM 的內(nèi)存表示（包括其熱度）會被序列化到磁盤上，這樣就可以在稍后的時間點（可能是在具有類似操作系統(tǒng)和 CPU 架構(gòu)的另一臺機器上）快速恢復?；謴秃蟮倪M程保留了 HotSpot JVM 的所有功能，包括運行時的進一步 JIT 優(yōu)化。

有趣的是，"檢查點 "和 "恢復 "與 Spring 應用上下文生命周期的停止和啟動階段非常匹配。

Spring Framework 6.1 的 CRaC 支持主要是將 CRaC 和 Spring 生命周期映射到一起，其他支持與 CRaC 無關，主要是對 Spring 生命周期的完善，旨在正確關閉和重新創(chuàng)建套接字、文件和池。除了常規(guī)的啟動和停止生命周期外，這里的目標是支持多個停止和重啟周期。

與 GraalVM 一樣，Project CRaC 允許應用程序從零擴展到零，即使在小型服務器上也能在幾十毫秒內(nèi)瞬間啟動。這比普通 JVM 冷啟動快 50 倍，與 GraalVM 本機鏡像類似。但是，讓我們來探討一下其中的利弊得失。

請記住，我們正處于 CRaC 項目的早期階段，Spring Boot 3.2 是支持 CRaC 的第一個版本。隨著檢查點還原技術和 Spring 支持的發(fā)展，其中一些限制可能會被取消。

4、通過 Spring AOT 和 Project Leyden 一窺 OpenJDK 的未來
我們已經(jīng)看到了通過 GraalVM 和 CRaC 將 Spring 工作負載擴展到零的兩種方法，但其中涉及到不小的權衡。如果有另一種方法可以在減少限制的情況下提高 Spring Boot 運行時特性，那會怎樣呢？

您可能聽說過 Project Leyden，這是一個新的 OpenJDK 項目，旨在改善 Java 程序的啟動時間、達到峰值性能的時間和占用空間。

Project Leyden 最近引入了 "premain "優(yōu)化（基本上是類數(shù)據(jù)共享 + AOT 的類固醇），有趣的是，Java Platform 團隊發(fā)現(xiàn)了 Spring Ahead-Of-Time 優(yōu)化的巨大協(xié)同作用，Spring Ahead-Of-Time 優(yōu)化最初是為了支持 GraalVM 原生鏡像而創(chuàng)建的，但已經(jīng)能夠?qū)?JVM 的啟動時間縮短 15%。

雖然 "premain "優(yōu)化是高度實驗性的（目前它只是 GitHub 上 Leyden 代碼庫的一個實驗性分支），但 Spring 團隊最近通過結(jié)合 JVM 上的 Spring AOT 和項目 Leyden 中的這些優(yōu)化，已經(jīng)測得 Spring Petclinic 示例應用程序的啟動時間縮短了 2 到 4 倍，預熱速度也加快了，而且?guī)缀鯖]有任何取舍。

與 GraalVM 和 CRaC 不同的是，這些優(yōu)化措施目前還無法實現(xiàn)零擴展，因為它們無法讓應用程序在生產(chǎn)中以幾十毫秒的速度啟動。但是，如果我們能在幾乎不受任何限制的情況下顯著改善 JVM 的啟動和預熱時間，那么它就有可能成為主流。

來自：https://www.jdon.com/69141.html