Spring 團隊剛剛釋出了 spring-graalvm-native 專案的 0.6.0 版本。該專案旨在讓任何試圖構建其 Spring 應用程式的 GraalVM 本機映像的人更容易上手。

有關 Spring 本機映像的深入瞭解，請參閱 Sébastien Deleuze 的 Devoxx 演講。

在這篇博文中，我們將討論自那時以來發生的變化，併為您指出一些關鍵資源，使您能夠嘗試它！該專案位於 spring-projects-experimental github 組織中，表明它仍在開發中，但我們有許多示例應用程式展示了已經可用的技術型別，以及大量關於如何使用您自己的應用程式進行試驗的文件。

什麼是 GraalVM 本機映像？

快速回顧一下，GraalVM 是一個傘形專案，可用於多種目的，但我們此處要關注的關鍵方面是將 JVM 程式碼作為本機映像執行。一旦編譯成特定於平臺的本機映像，應用程式應具有非常快的啟動速度和更可靠的記憶體配置檔案（沒有 JIT 在開始時導致記憶體峰值）。

建立映像時，本機映像構建工具需要了解您的應用程式資訊，例如載入了哪些資源、可能正在反射哪些型別，以及型別是在映像構建時安全初始化還是必須在執行時稍後初始化。此資訊使本機映像工具能夠嘗試為應用程式構建最佳映像。

實際上有幾種收集和通訊此配置的方法

• 一些庫直接在其分發版中包含它，作為固定的 .json 檔案（例如 netty）
• 第三方功能（在 GraalVM 術語中）參與構建過程，計算資訊並透過 API 將其傳遞給本機映像。spring-graalvm-native 專案的一個關鍵方面是它所包含的功能。此功能瞭解 Spring Boot 應用程式如何操作，將該知識應用於正在構建的特定應用程式，並將結果傳遞給本機映像構建過程。它可以在封閉世界假設下做出非常動態的決策，知道在映像構建發生時類路徑是完整/固定的。
• GraalVM 提供的代理可以在應用程式正常執行（作為 JVM 應用程式）時收集必要的配置資料，然後這些檔案由後續的本機映像構建步驟獲取。

這些計算配置的方法各有利弊。例如，代理只能收集應用程式執行時執行的程式碼路徑上的資訊，但它肯定會建立一套精確所需（在資源/反射訪問方面）的最佳配置。另一方面，該功能不會建立完全最佳的配置，因為它不執行應用程式，因此必須允許某些可能或可能不採用的程式碼路徑，但作為構建過程的一部分，該功能可以執行 Spring 特定的最佳化，例如急切地評估條件配置。當本機映像構建執行時，已知完整的類路徑，因此可以在那時執行 @ConditionalOnClass 檢查，如果它們失敗，則可以丟棄該配置，甚至在生成的映像啟動時也不再檢視。

我們一直在這些方面努力工作，試圖改善生態系統，以便我們能夠走向一個一切都能正常工作的世界。還有很長的路要走！我們正在深入研究 Tomcat，以使其配置像 Netty 一樣容易獲取。與 GraalVM 團隊一起，我們一直在確保 Spring Boot 應用程式中沒有任何會阻礙本機映像構建的東西（需要雙方進行修復），並改進 spring-graalvm-native 功能以更好地理解更廣泛的 Spring 應用程式。我們還一直在幫助確保代理收集器沒有遺漏任何東西。我們目前正在與 GraalVM 團隊一起解決的問題實際上在此處跟蹤。

自 Spring One Platform 2019 和 Devoxx 的演示以來，該功能對 Boot 瞭解更多，代理遺漏更少，GraalVM 相容性更高，生成的映像大小減小，映像構建時間縮短，我們甚至包含了更多示例專案來演示正在工作的內容。

我怎麼嘗試呢？

這裡有許多示例專案此處，甚至包括一個 PetClinic（當然！）以及此處的示例相關文件，介紹如何使用它們。有使用 Netty、Tomcat、Spring MVC、Spring WebFlux、JPA、Spring Cloud Function、Kotlin 等的示例。您可能會看到什麼？

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::
...
INFO: Started TomcatApplication in 0.044 seconds (JVM running for 0.62)

對於將其應用於您自己的專案，文件描述了所有步驟，無論是使用該功能、代理還是涉及兩者的混合模式來執行它。混合模式有時是兩全其美的方法，因為代理可以捕獲功能可能遺漏的東西，反之亦然。

當它不起作用時我該怎麼辦？

這個過程還沒有完全順暢，許多領域仍有待改進。負責該功能的團隊和 GraalVM 團隊都在努力改進診斷，以便當出現問題時，您仍然可以取得進展並瞭解下一步該怎麼做。某個隨機應用程式第一次就正常工作的可能性不大，但對於致力於解決問題的任何人來說，許多應用程式都將正常工作。您的應用程式可能正在使用我們測試中尚未遇到的庫。它可能正在使用該功能尚未了解的 Spring 行為。它可能在映像構建時或在編譯映像啟動時的執行時出錯。有一故障排除頁面，討論了一些常見問題以及如何解決它們。遇到其他問題？請在專案上提出問題。

在 spring-graalvm-native 專案中有一個配置子專案，它試圖以易於擴充套件的形式封裝關於 Spring Boot 行為的知識。例如，它編碼了一個特定的匯入選擇器可能需要對特定型別進行反射訪問。該功能本身由這種封裝的知識驅動，如果您發現知識目前不足，請隨時增強它並貢獻回專案以擴充套件該知識，請參閱可擴充套件性指南。

spring-graalvm-native 專案中還包含一些替換項，替換是 GraalVM 的一個術語，指在映像構建時對現有類進行更改，該現有類當前在本機映像中包含時無法正常工作。隨著時間的推移，計劃仍然是消除這些替換項，並與包含這些有問題類的專案合作，使它們達到可以在本機映像內部或外部工作的理想形式。

儘管 spring-graalvm-native 專注於 Spring，但顯然 Spring 專案通常包含許多第三方依賴項。其中許多尚未包含必要的配置，因此我們的功能正在盡力“彌補”它們。在可能的情況下，我們的計劃仍然是與這些依賴項提供商合作，幫助他們製作理想的本機映像配置，然後它將簡單地由本機映像構建自動獲取。GraalVM 代理提供了一種很好的方法來嘗試處理缺少配置的程式碼。

前方的道路

所有工作都只發生在這個實驗性功能中嗎？遠非如此。Spring 中已經進行了一些增強，以確保它在構建成本機映像時正常執行。例如，在 Spring Framework 中，Spring Framework 5.2 中的 @Configuration proxyBeanMethods 屬性使應用程式無需 CGLIB 代理即可執行（本機映像過程只能支援 JDK 代理）。我們還在 Spring Boot 條件處理中重構了一些類載入，以使用不同的方法，因為代理無法捕獲原始的載入形式。

更多這樣的增強功能將陸續推出。還有更多東西需要教給該功能，而在核心 Spring 中，啟動時仍有太多工作可以推到構建時，這將嚴重影響構建的本機映像的記憶體需求。這些改進不僅會使構建成本機映像的應用程式受益，還會使在常規 JVM 上執行的應用程式受益。情況只會越來越好！感謝 GraalVM 團隊在此工作中對我們的支援。要跟蹤我們的進展，請關注該專案。