GraalVM Native Image 基础：构建期与运行期、镜像堆与静态分析原理详解

GraalVM Native Image 基础构建期与运行期、镜像堆与静态分析原理详解【免费下载链接】graalGraalVM compiles applications into native executables that start instantly, scale fast, and use fewer compute resources 项目地址: https://gitcode.com/gh_mirrors/gr/graal本文以 GraalVM Native Image 的核心机制为主线系统讲解native-image构建器如何把 Java 字节码加工成独立的原生可执行文件或共享库重点厘清三个最基础也最关键的概念——构建期Build Time与运行期Run Time、镜像堆Native Image Heap、静态分析Static Analysis与闭世界假设Closed-World Assumption。读完本文你将能够看懂native-image构建日志中每一阶段的含义正确使用--initialize-at-build-time/--initialize-at-run-time等类初始化选项并理解为什么反射、序列化等动态特性需要额外的可达性元数据Reachability Metadata。从字节码到原生二进制的三步走Native Image 本身是用 Java 编写的它以Java 字节码Java bytecode作为输入产出一个独立的二进制产物——可以是可执行文件executable也可以是共享库shared library。整个产出过程包含三个关键环节构建期间执行用户代码在产出二进制的过程中Native Image 可以在宿主 JVM 上运行一部分用户代码典型场景就是类初始化。链接把编译后的用户代码、Java 运行时的一部分例如垃圾回收器、线程支持等以及代码执行产生的结果一起链接进二进制。产出最终得到被称作native executable原生可执行文件或native image原生镜像的产物。与之对应产出该二进制的工具被称为native-imagebuildernative-image构建器或native-imagegeneratornative-image生成器。为了严格区分在构建期间执行的代码与在运行期间执行的代码Native Image 引入了本文的核心概念之一构建期与运行期。native-image命令的三种典型用法详见仓库中的 Native Image Build Overview为# 从当前目录下的主类构建 native-image [options] mainclass [imagename] [options] # 从 JAR 文件构建 native-image [options] -jar jarfile [imagename] [options] # 从 Java 模块构建 native-image [options] -m module/mainClass [imagename] [options]选项从左到右依次求值类路径通过-cp classpath指定Linux/macOS 上以冒号分隔Windows 上以分号分隔。构建期Build Time与运行期Run Time两个阶段如何划分构建期build time指镜像构建过程中在宿主 JVM 上执行的代码。这段代码可以产生副作用例如向某个类的静态字段写入值。这些被写入的值会被保存进镜像堆中。运行期run time指二进制产物镜像被实际执行时对应的代码与状态。理解这两个概念最直观的入口是可配置的类初始化configurable class initialization。在 Java 语义中一个类在首次被使用时才会被初始化而在 Native Image 中每个在构建期被使用过的 Java 类都被称为构建期初始化build-time initialized。需要注意仅仅**加载load**一个类并不一定会初始化它。构建期初始化类的静态初始化器static initializer实际运行在执行镜像构建的 JVM 上。如果一个类在构建期被初始化它的静态字段会被保存进最终产出的二进制中在运行期即使第一次使用这个类也不会再次触发类初始化。用户在两种典型场景下会触发构建期类初始化给native-image构建器传递--initialize-at-build-timeclass参数在一个构建期初始化的类的静态初始化器中使用了另一个类。Native Image 默认会在镜像构建期初始化大量高频使用的 JDK 类例如java.lang.String、java.util.**等。需要强调的是构建期类初始化是一个专家级特性并非所有类都适合在构建期初始化——错误的配置可能导致运行期行为异常甚至把敏感数据如密码、密钥固化进二进制。用 HelloWorld 演示构建期与运行期的差别原文档给出了如下示例NativeImageBasics.md我们将它完整展开。把代码保存为_HelloWorld.java_public class HelloWorld { static class Greeter { static { System.out.println(Greeter is getting ready!); } public static void greet() { System.out.println(Hello, World!); } } public static void main(String[] args) { Greeter.greet(); } }先在 JVM 上编译并运行观察类初始化发生的时机javac HelloWorld.java java HelloWorld Greeter is getting ready! Hello, World!接着用默认配置构建原生镜像并执行native-image HelloWorld GraalVM Native Image: Generating helloworld (executable)... ... Finished generating helloworld in 14.9s../helloworld Greeter is getting ready! Hello, World!程序启动后调用Greeter.greet触发了Greeter的类初始化打印出Greeter is getting ready!。此时我们说Greeter的类初始化器在镜像运行期执行。现在换一种方式显式要求native-image在构建期初始化Greeternative-image HelloWorld --initialize-at-build-timeHelloWorld\$Greeter GraalVM Native Image: Generating helloworld (executable)... Greeter is getting ready! [1/8] Initializing... (3.1s 0.15GB) Java version: 2436, vendor version: Oracle GraalVM 2436.1 Graal compiler: optimization level: 2, target machine: armv8.1-a, PGO: ML-inferred C compiler: cc (apple, arm64, 16.0.0) Garbage collector: Serial GC (max heap size: 80% of RAM) ... Finished generating helloworld in 13.6s. ./helloworld Hello, World!注意输出顺序的变化Greeter is getting ready!出现在镜像构建期间紧跟构建器横幅之后、进入[1/8] Initializing...之前——Greeter的类初始化器在镜像构建期执行运行./helloworld时只剩Hello, World!因为运行期HelloWorld调用Greeter.greet时Greeter已经处于已初始化状态构建期间初始化过的类的静态字段会被存储进镜像堆。从源码看类初始化选项的实现上述行为在仓库源码中有明确的实现对应。类初始化的核心选项定义在 ClassInitializationOptions.java--initialize-at-build-time接收一个逗号分隔的包名/类名列表以及隐式的所有父类在镜像生成期间初始化空字符串表示所有包。--initialize-at-run-time接收一个逗号分隔的包名/类名列表以及隐式的所有子类必须在运行期初始化空字符串当前不支持。-H:PrintClassInitialization对应PrintClassInitialization选项打印分析检测到的所有类的类初始化信息用于排查哪些类为什么被初始化。选项的解析与校验逻辑位于 ClassInitializationFeature.java构建器会逐个拆解逗号分隔的值根据后缀判定是构建期初始化还是运行期初始化并最终调用initializeAtBuildTime/initializeAtRunTime注册到初始化支持类中。此外com.oracle.svm与com.oracle.graal等 Native Image 自身的包总是被强制在构建期初始化NATIVE_IMAGE_CLASS_REASON。关于类初始化策略更完整的讨论包括安全类自动构建期初始化、-H:PrintClassInitialization的使用等请继续阅读仓库文档 Class Initialization in Native Image。镜像堆Native Image Heap镜像堆里有什么Native Image 堆也叫image heap镜像堆包含三类内容镜像构建期间创建、且从应用程序代码可达的对象典型来源就是构建期类的静态字段所引用的对象原生镜像中使用的所有java.lang.Class对象的对应体在 Native Image 运行时由DynamicHub表示参见 DynamicHub.java内嵌在方法代码中的对象常量object constants——详见 ReachabilityMetadata。当原生镜像启动时它会把初始镜像堆从二进制中整体拷贝出来作为运行期堆的起点。这正是把工作从运行期挪到构建期能够显著加速启动的根本原因大量对象在构建期就已经被创建、序列化进二进制运行期只需按地址拷贝即可。用 System Property 演示镜像堆原文档给出了一个非常经典的示例我们完整保留。把代码保存为_Example.java_class Example { private static final String message; static { message System.getProperty(message); } public static void main(String[] args) { System.out.println(Hello, World! My message is: message); } }先在 JVM 上编译并运行注意-Dmessage的值随命令行变化javac Example.java java -Dmessagehi Example Hello, World! My message is: hijava -Dmessagehello Example Hello, World! My message is: hellojava Example Hello, World! My message is: null现在构建一个把Example放在构建期初始化的原生镜像并在构建时传入-Dmessagenativenative-image Example --initialize-at-build-timeExample -Dmessagenative GraalVM Native Image: Generating example (executable)... ... Finished generating example in 19.0s../example Hello, World! My message is: native./example -DmessageaNewMessage Hello, World! My message is: native关键结论Example的类初始化器在镜像构建期执行读取了构建期 JVM 的属性-Dmessagenative为message字段创建了一个String对象这个String对象被存储进镜像堆并固化在二进制中运行期即使通过./example -DmessageaNewMessage传入了新属性message依然是构建期固化的值native——因为类已经初始化过了静态字段不会再重新计算。这正是构建期状态进入镜像堆的直接体现镜像堆是构建期执行结果的快照。从源码看镜像堆镜像堆的构建与写入在构建器侧由多个类协作完成其中核心之一是本仓库中的 NativeImageHeap.java它负责收集、排序、编码镜像堆中的对象最终由NativeImageHeapWriter等组件写入二进制。与之配合的还有ImageHeapCollectionFeature、ImageHeapObjectAdder、ImageHeapConnectedComponentsFeature等实现类位于 heap 与 image 目录它们共同决定哪些对象进入镜像堆、以什么顺序布局。一个实用的运行期排查手段如果某个对象在运行期被访问时报错提示其类型未被--initialize-at-build-time标记见 ClassInitializationFeature.java 附近对 objects ended up in the image heap without their type being marked 的检测与告警说明该对象的产生路径需要显式配置构建期初始化或者改为在运行期创建。静态分析Static Analysis什么是可达代码静态分析是决定一个应用程序到底使用了哪些程序元素类、方法、字段的过程被判定为使用的元素称为可达代码reachable code。只有可达的元素才会被包含进最终镜像。分析本身由两部分组成扫描方法的字节码确定从这个方法还能触达哪些其他元素扫描镜像堆中的根对象例如静态字段确定从这些对象还能触达哪些类。整个分析从应用的入口点即main方法出发不断迭代扫描新发现的元素直到某次扫描不再改变任何元素的可达性达到不动点为止。迭代分析在源码中的体现这一迭代至不动点的机制在仓库源码中有明确实现。分析引擎的主循环位于 AbstractAnalysisEngine.java 的runAnalysis方法中循环内反复调用finish()执行一轮分析直到analysisEndCondition返回真如果迭代超过 1000 次仍未收敛会抛出错误提示静态分析没有达到不动点正常情况通常少于 10 次迭代。可执行的根方法与根对象的注册如addRootMethod则由 ReachabilityAnalysis.java 等类提供。闭世界假设Closed-World Assumption镜像构建完成之后运行期不能再加入任何新的元素——例如通过类加载class loading动态添加类是不被允许的。这一约束被称为闭世界假设closed-world assumption。它是理解 Native Image 一切行为的总纲因为世界在构建期闭合所以才能放心剔除不可达代码做到极小的二进制体积也正因为世界闭合反射reflection、JNI、资源访问、序列化、动态代理等依赖运行期动态查找的 JVM 特性必须通过**可达性元数据Reachability Metadata**在构建期显式声明否则运行期会抛出缺失注册错误如MissingReflectionRegistrationError。相关内容可参阅 Reachability Metadata 文档其中也解释了如何在代码中提供常量参数如Class.forName(Foo)让构建器在构建期自动求值并存入初始镜像堆——这恰好把本文的构建期/运行期与镜像堆两个概念联系了起来。实战进阶构建期与运行期类初始化的性能对比为了更直观地体会构建期初始化带来的收益仓库配套指南 Specify Class Initialization Explicitly 提供了一个完整的TalkParser演示解析一段文本块并生成Talk记录列表。import java.util.ArrayList; import java.util.List; import java.util.Scanner; public class TalkParser { private static final ListTalk TALKS new ArrayList(); static { Scanner s new Scanner( Asynchronous Programming in Java: Options to Choose from by Venkat Subramaniam Anatomy of a Spring Boot App with Clean Architecture by Steve Pember Java in the Cloud with GraalVM by Alina Yurenko Bootiful Spring Boot 3 by Josh Long ); while (s.hasNextLine()) { TALKS.add(new Talk(s.nextLine())); } s.close(); } public static void main(String[] args) { System.out.println(Talks loaded using scanner:); for (Talk talk : TALKS) { System.out.println(- talk.name()); } } } record Talk (String name) {}编译后分别做两次构建javac TalkParser.java # 运行期初始化默认行为也可显式声明 native-image --initialize-at-run-timeTalkParser,Talk -o runtime-parser TalkParser # 构建期初始化 native-image --initialize-at-build-timeTalkParser,Talk -o buildtime-parser TalkParser实测对比不同机器结果不同重点看趋势运行期初始化版本解析逻辑保留在二进制中运行期才执行Scanner解析产物体积约13M构建期初始化版本文本块在构建期就被解析完二进制中只固化解析得到的Talk记录产物体积下降到约6.4M用perf stat观察指令数构建期初始化版本从约 11.8M 条指令下降到约 8.6M 条降幅接近 30%——因为大部分解析基础组件Scanner相关在静态分析时已不可达被整体剔除。该指南还给出了两条重要建议--initialize-at-build-time尽量只针对单个类使用错误的构建期初始化可能把敏感数据如密码、加密密钥固化进二进制生产环境需格外谨慎。小结与进一步阅读本文梳理了 GraalVM Native Image 的三大基石构建期 vs 运行期理解代码与状态在哪个阶段产生是使用--initialize-at-build-time/--initialize-at-run-time的前提镜像堆构建期结果被固化进二进制的载体也是启动加速的来源静态分析与闭世界假设决定哪些代码进入镜像也解释了为什么动态特性需要元数据。在此基础上建议继续阅读仓库中的以下文档以构建完整知识体系Native Image Build Overviewnative-image命令语法、构建完成通知技巧Class Initialization in Native Image类初始化的性能影响、安全类自动构建期初始化策略与约束Specify Class Initialization Explicitly类初始化配置的完整实战演练Reachability Metadata闭世界假设下反射、JNI、资源、序列化等动态特性的元数据配置参考。【免费下载链接】graalGraalVM compiles applications into native executables that start instantly, scale fast, and use fewer compute resources 项目地址: https://gitcode.com/gh_mirrors/gr/graal创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考