GraalVM 原生映像檔簡介

GraalVM 原生映像檔提供了一種部署和執行 Java 應用程式的新方法。與 Java 虛擬機器相比，原生映像檔可以用更小的記憶體佔用量和更快的啟動時間執行。

它們非常適合使用容器映像檔部署的應用程式，並且在與「函式即服務」(FaaS) 平台結合使用時尤其令人感興趣。

與為 JVM 編寫的傳統應用程式不同，GraalVM 原生映像檔應用程式需要預先編譯處理才能建立可執行檔。這種預先編譯處理涉及從應用程式的主要進入點靜態分析您的應用程式程式碼。

GraalVM 原生映像檔是一個完整的、平台特定的可執行檔。您無需運送 Java 虛擬機器即可執行原生映像檔。

如果您只是想開始並試用 GraalVM，您可以跳到開發您的第一個 GraalVM 原生應用程式章節，稍後再返回本節。

與 JVM 部署的主要差異

GraalVM 原生映像檔是預先產生的，這意味著原生應用程式和基於 JVM 的應用程式之間存在一些主要差異。主要差異在於

您的應用程式的靜態分析在建置時從 main 進入點執行。
在建立原生映像檔時無法存取的程式碼將被移除，並且不會成為可執行檔的一部分。
GraalVM 無法直接感知程式碼的動態元素，必須告知反射、資源、序列化和動態代理。
應用程式類別路徑在建置時是固定的，並且無法變更。
沒有延遲類別載入，可執行檔中運送的所有內容都將在啟動時載入記憶體。
Java 應用程式的某些方面存在一些限制，這些方面未完全支援。

除了這些差異之外，Spring 還使用一個稱為 Spring 預先編譯處理的程序，這施加了進一步的限制。請務必至少閱讀下一節的開頭，以了解這些限制。

GraalVM 參考文件中的原生映像檔相容性指南章節提供了有關 GraalVM 限制的更多詳細資訊。

了解 Spring 預先編譯處理

典型的 Spring Boot 應用程式非常動態，組態在執行時執行。實際上，Spring Boot 自動組態的概念很大程度上取決於對執行時狀態做出反應，以便正確組態事物。

儘管可以將應用程式的這些動態方面告知 GraalVM，但這樣做會消除靜態分析的大部分優勢。因此，相反，當使用 Spring Boot 建立原生映像檔時，會假定一個封閉的世界，並且應用程式的動態方面受到限制。

封閉世界假設除了 GraalVM 本身造成的限制之外，還暗示了以下限制

應用程式中定義的 Bean 無法在執行時變更，這表示
- Spring @Profile 註解和設定檔特定的組態有限制。
- 如果建立 Bean，則不支援變更的屬性（例如，@ConditionalOnProperty 和 .enable 屬性）。

當這些限制到位時，Spring 可以在建置時執行預先編譯處理，並產生 GraalVM 可以使用的其他資產。Spring AOT 處理的應用程式通常會產生

Java 原始碼
位元組碼（用於動態代理等）
GraalVM JSON 提示檔
- 資源提示 (resource-config.json)
- 反射提示 (reflect-config.json)
- 序列化提示 (serialization-config.json)
- Java 代理提示 (proxy-config.json)
- JNI 提示 (jni-config.json)

原始碼生成

Spring 應用程式由 Spring Bean 組成。在內部，Spring Framework 使用兩個不同的概念來管理 Bean。有 Bean 實例，它們是已建立並可以注入到其他 Bean 中的實際實例。還有 Bean 定義，用於定義 Bean 的屬性以及應如何建立其實例。

如果我們採用典型的 @Configuration 類別

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration(proxyBeanMethods = false)
public class MyConfiguration {

	@Bean
	public MyBean myBean() {
		return new MyBean();
	}

}

Bean 定義是透過剖析 @Configuration 類別並尋找 @Bean 方法來建立的。在上面的範例中，我們正在為名為 myBean 的單例 Bean 定義 BeanDefinition。我們也正在為 MyConfiguration 類別本身建立 BeanDefinition。

當需要 myBean 實例時，Spring 知道它必須調用 myBean() 方法並使用結果。在 JVM 上執行時，@Configuration 類別剖析發生在應用程式啟動時，並且使用反射調用 @Bean 方法。

在建立原生映像檔時，Spring 以不同的方式運作。它不是在執行時剖析 @Configuration 類別並產生 Bean 定義，而是在建置時執行此操作。一旦發現 Bean 定義，就會對其進行處理並轉換為可以由 GraalVM 編譯器分析的原始碼。

Spring AOT 程序會將上面的組態類別轉換為如下程式碼

import org.springframework.beans.factory.aot.BeanInstanceSupplier;
import org.springframework.beans.factory.config.BeanDefinition;
import org.springframework.beans.factory.support.RootBeanDefinition;

/**
 * Bean definitions for {@link MyConfiguration}.
 */
public class MyConfiguration__BeanDefinitions {

	/**
	 * Get the bean definition for 'myConfiguration'.
	 */
	public static BeanDefinition getMyConfigurationBeanDefinition() {
		Class<?> beanType = MyConfiguration.class;
		RootBeanDefinition beanDefinition = new RootBeanDefinition(beanType);
		beanDefinition.setInstanceSupplier(MyConfiguration::new);
		return beanDefinition;
	}

	/**
	 * Get the bean instance supplier for 'myBean'.
	 */
	private static BeanInstanceSupplier<MyBean> getMyBeanInstanceSupplier() {
		return BeanInstanceSupplier.<MyBean>forFactoryMethod(MyConfiguration.class, "myBean")
			.withGenerator((registeredBean) -> registeredBean.getBeanFactory().getBean(MyConfiguration.class).myBean());
	}

	/**
	 * Get the bean definition for 'myBean'.
	 */
	public static BeanDefinition getMyBeanBeanDefinition() {
		Class<?> beanType = MyBean.class;
		RootBeanDefinition beanDefinition = new RootBeanDefinition(beanType);
		beanDefinition.setInstanceSupplier(getMyBeanInstanceSupplier());
		return beanDefinition;
	}

}

產生的確切程式碼可能會因 Bean 定義的性質而異。

您可以在上面看到，產生的程式碼建立了與 @Configuration 類別等效的 Bean 定義，但以 GraalVM 可以理解的直接方式。

有一個用於 myConfiguration Bean 的 Bean 定義，以及一個用於 myBean 的 Bean 定義。當需要 myBean 實例時，會調用 BeanInstanceSupplier。此供應商將調用 myConfiguration Bean 上的 myBean() 方法。

在 Spring AOT 處理期間，您的應用程式會啟動到 Bean 定義可用的程度。在 AOT 處理階段不會建立 Bean 實例。

Spring AOT 將為您的所有 Bean 定義產生像這樣的程式碼。當需要 Bean 後處理時（例如，調用 @Autowired 方法），它也會產生程式碼。還將產生一個 ApplicationContextInitializer，Spring Boot 將使用它在實際執行 AOT 處理的應用程式時初始化 ApplicationContext。

儘管 AOT 產生的原始碼可能很冗長，但它非常易讀，並且在偵錯應用程式時可能很有用。使用 Maven 時，產生的原始碼檔案可以在 target/spring-aot/main/sources 中找到，而使用 Gradle 時可以在 build/generated/aotSources 中找到。

提示檔生成

除了產生原始碼檔案外，Spring AOT 引擎還將產生 GraalVM 使用的提示檔。提示檔包含 JSON 資料，描述 GraalVM 應如何處理無法透過直接檢查程式碼來理解的事物。

例如，您可能在私有方法上使用 Spring 註解。Spring 將需要使用反射才能調用私有方法，即使在 GraalVM 上也是如此。當發生這種情況時，Spring 可以編寫反射提示，以便 GraalVM 知道即使私有方法未直接調用，它仍然需要在原生映像檔中可用。

提示檔在 META-INF/native-image 下產生，GraalVM 會自動拾取它們。

使用 Maven 時，產生的提示檔可以在 target/spring-aot/main/resources 中找到，而使用 Gradle 時可以在 build/generated/aotResources 中找到。

代理類別生成

Spring 有時需要產生代理類別，以使用其他功能增強您編寫的程式碼。為此，它使用 cglib 函式庫，該函式庫直接產生位元組碼。

當應用程式在 JVM 上執行時，代理類別會在應用程式執行時動態產生。在建立原生映像檔時，需要在建置時建立這些代理，以便 GraalVM 可以包含它們。

與原始碼生成不同，產生的位元組碼在偵錯應用程式時並不是特別有用。但是，如果您需要使用諸如 javap 之類的工具檢查 .class 檔案的內容，則可以在 Maven 的 target/spring-aot/main/classes 和 Gradle 的 build/generated/aotClasses 中找到它們。