介绍 GraalVM Native Images

QWen Max 中英对照 Introducing GraalVM Native Images

GraalVM Native Images 提供了一种部署和运行 Java 应用程序的新方式。与 Java 虚拟机相比，原生镜像可以以更小的内存占用和更快的启动时间运行。

它们非常适合使用容器镜像部署的应用程序，尤其在与“函数即服务”（Function as a Service，FaaS）平台结合使用时更具吸引力。

与为 JVM 编写的传统应用程序不同，GraalVM Native Image 应用程序需要提前进行处理才能生成可执行文件。这种提前处理涉及从应用程序的主入口点开始对其代码进行静态分析。

GraalVM Native Image 是一个完整的、平台特定的可执行文件。你无需附带 Java 虚拟机（JVM）即可运行 native image。

提示

如果你只是想快速开始并体验 GraalVM，可以直接跳转到 开发你的第一个 GraalVM 原生应用 章节，稍后再回到本节。

与 JVM 部署的关键差异

GraalVM Native Image 是提前（ahead-of-time）生成的，这一事实意味着原生应用与基于 JVM 的应用之间存在一些关键差异。主要差异包括：

• 应用程序的静态分析在构建时从 main 入口点执行。

• 在创建原生镜像时无法到达的代码将被移除，并不会包含在可执行文件中。

• GraalVM 无法直接感知代码中的动态元素，必须显式告知其关于反射、资源、序列化和动态代理的信息。

• 应用程序的类路径在构建时固定，无法更改。

• 没有延迟类加载机制，可执行文件中包含的所有内容都会在启动时加载到内存中。

• Java 应用程序的某些方面存在一些限制，这些方面尚未得到完全支持。

除了上述差异之外，Spring 还使用了一种称为 Spring Ahead-of-Time processing 的流程，这会带来进一步的限制。请务必至少阅读下一节的开头部分，以了解这些限制。

提示

GraalVM 参考文档中的 Native Image 兼容性指南 章节提供了有关 GraalVM 限制的更多详细信息。

理解 Spring 提前编译（Ahead-of-Time）处理

典型的 Spring Boot 应用程序具有相当的动态性，配置是在运行时进行的。事实上，Spring Boot 自动配置的概念在很大程度上依赖于对运行时状态的响应，以便正确地进行配置。

尽管可以将这些应用程序的动态特性告知 GraalVM，但这样做会抵消静态分析带来的大部分优势。因此，在使用 Spring Boot 创建原生镜像时，会假定一个封闭世界（closed-world），并对应用程序的动态特性加以限制。

封闭世界假设（closed-world assumption）除了 GraalVM 本身所带来的限制 之外，还意味着以下限制：

• 应用程序中定义的 bean 在运行时无法更改，这意味着：

  • Spring 的 @Profile 注解和基于 profile 的配置 存在限制。

  • 不支持根据 bean 是否创建而变化的属性（例如，@ConditionalOnProperty 和 .enabled 属性）。

当这些限制生效时，Spring 就可以在构建时执行预先处理（ahead-of-time processing），并生成 GraalVM 可以使用的额外资源。经过 Spring AOT 处理的应用程序通常会生成：

• Java 源代码

• 字节码（用于动态代理等）

• META-INF/native-image/{groupId}/{artifactId}/ 目录下的 GraalVM JSON 提示文件：

  • 资源提示（resource-config.json）

  • 反射提示（reflect-config.json）

  • 序列化提示（serialization-config.json）

  • Java 代理提示（proxy-config.json）

  • JNI 提示（jni-config.json）

如果生成的提示（hints）不够充分，你也可以 提供自己的提示。

源代码生成

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。该 supplier 将在 myConfiguration bean 上调用 myBean() 方法。

备注

在 Spring AOT 处理期间，您的应用程序会启动到 Bean 定义可用的阶段。在 AOT 处理阶段不会创建 Bean 实例。

Spring AOT 将为你的所有 bean 定义生成类似这样的代码。当需要进行 bean 后处理时（例如，调用 @Autowired 方法），它也会生成相应的代码。此外，还会生成一个 ApplicationContextInitializer，当运行经过 AOT 处理的应用程序时，Spring Boot 会使用该初始化器来初始化 ApplicationContext。

提示

尽管 AOT 生成的源代码可能较为冗长，但它具有很好的可读性，在调试应用程序时非常有帮助。使用 Maven 时，生成的源文件位于 target/spring-aot/main/sources 目录下；使用 Gradle 时，则位于 build/generated/aotSources 目录下。

Hint 文件生成

除了生成源代码文件外，Spring AOT 引擎还会生成 GraalVM 使用的提示文件（hint files）。提示文件包含 JSON 数据，用于描述 GraalVM 应该如何处理那些无法通过直接检查代码而理解的内容。

例如，你可能在一个私有方法上使用了 Spring 注解。即使在 GraalVM 上，Spring 也需要使用反射来调用私有方法。当出现这种情况时，Spring 可以写入一个反射提示（reflection hint），以便 GraalVM 知道：尽管该私有方法没有被直接调用，但仍需在原生镜像中保留该方法。

Hint 文件在 META-INF/native-image 目录下生成，GraalVM 会自动拾取这些文件。

提示

使用 Maven 时，生成的 hint 文件位于 target/spring-aot/main/resources；使用 Gradle 时，位于 build/generated/aotResources。

代理类生成

Spring 有时需要生成代理类，以向你编写的代码中添加额外功能。为此，它使用 cglib 库直接生成字节码。

当应用程序在 JVM 上运行时，代理类会在应用程序运行过程中动态生成。在创建原生镜像（native image）时，这些代理需要在构建时生成，以便 GraalVM 能够将其包含进去。

备注

与源代码生成不同，生成的字节码在调试应用程序时并不是特别有用。然而，如果你需要使用诸如 javap 之类的工具检查 .class 文件的内容，可以在 Maven 项目的 target/spring-aot/main/classes 目录下，或 Gradle 项目的 build/generated/aotClasses 目录下找到它们。