第一章：高性能 Web 引擎：深入 Undertow

在本章中，我们将循序渐进，像一名专业的汽车工程师一样，首先从更换引擎开始，为我们的应用注入更强劲的动力：

1. 首先，我们将诊断现有引擎 Tomcat 在高负载下的 性能瓶颈。
2. 接着，我们将对两款引擎 Tomcat 与 Undertow 进行详细的 架构对比，理解其优劣。
3. 然后，我们将进入车间，动手 实战替换 为 Undertow。
4. 最后，我们将学习如何对新引擎 Undertow 进行 参数调优，榨干其最后一滴性能。

1.1. 痛点重现：Tomcat 在高并发下的线程模型瓶颈

在序章中我们提到，性能优化的起点是识别瓶颈。对于绝大多数 Spring Boot 应用而言，第一个迎接用户请求的组件便是 Web 容器，而默认的 Tomcat 在某些场景下，恰恰是那块最容易出现裂痕的短板。

痛点背景: 设想一个典型的电商系统，在“双十一”大促零点开启的瞬间，海量用户请求（查询商品、下单、检查库存）如潮水般涌入。这些操作绝大多数都属于 I/O 密集型 任务——程序的大部分时间都在等待数据库返回数据、等待调用下游微服务、等待消息队列响应。

Tomcat 采用的是经典的 一个请求一个平台线程 模型。这意味着每一个用户请求都会占用一个线程池中的线程，直到该请求完全处理完毕。在高并发的 I/O 密集型场景下，成千上万的线程被创建出来，但它们中的绝大多数都在 傻等 I/O 操作完成，白白占用了宝贵的内存资源（每个线程栈大约需要 1MB），并给 CPU 带来了巨大的上下文切换开销，最终导致系统响应缓慢甚至宕机。

解决方案: 要打破这个瓶颈，我们需要一个更现代的 Web 容器，它采用更高效的 I/O 模型和线程模型，能够在线程等待 I/O 时将其释放，从而用更少的线程处理更多的请求。这便是 Undertow 等高性能容器的核心价值所在。

1.2. 架构对决：Tomcat vs. Undertow

明确了 Tomcat 的瓶颈后，让我们通过一场“架构对决”，来理解为什么 Undertow 是一个更优的选择。

痛点背景: 面对技术选型，如果只停留在“听说 Undertow 更快”的层面，是无法做出专业决策的。我们需要深入其内部，理解两者在核心设计上的根本差异，才能在面试和技术方案设计中言之有物。

解决方案: 我们将从三个核心维度对两者进行对比。

1.3. [实战] 一键替换：迁移到 Undertow

理论分析完毕，现在让我们进入实战环节。您会发现，得益于 Spring Boot 强大的抽象和自动化配置，迁移到 Undertow 的过程异常简单。

痛点背景: 任何有侵入性的技术改造都会让工程师感到担忧。复杂的迁移流程、大量的代码改动，都可能成为阻碍项目优化的巨大障碍。

解决方案: 在 Spring Boot 中，Web 容器是可插拔的。我们只需要通过 Maven (或 Gradle) 调整依赖，无需改动任何一行 Java 代码。

假设我们的项目 pom.xml 中有如下标准 Web 依赖：

1
2
3
4

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

我们只需做两步修改：

1. 在 spring-boot-starter-web 中 排除 内嵌的 Tomcat。
2. 引入 Undertow 的 starter。

文件路径: pom.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>

完成修改并重新加载 Maven 依赖后，直接启动您的 Spring Boot 应用。观察控制台的启动日志。

1
2
3
4
5
6
7
8
9
# 修改前 (使用 Tomcat)
... o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
... o.apache.catalina.core.StandardService   : Starting service [Tomcat]
... o.apache.catalina.core.StandardEngine  : Starting Servlet engine: [Apache Tomcat/10.1.24]

# 修改后 (使用 Undertow)
... io.undertow.Undertow                           : starting server: Undertow - 2.3.12.Final
... org.xnio                                     : XNIO version 3.9.5.Final
... o.s.b.w.e.undertow.UndertowWebServer     : Undertow started on port(s) 8080 (http)

如上所示，当您看到日志中出现 Undertow 和 XNIO 的字样时，恭喜您，引擎已经替换成功！

1.4. [实战] 参数调优：榨干 Undertow 的性能

仅仅替换了引擎，我们只是获得了一个更好的基础。要想让它在您的特定业务场景下发挥最大威力，合理的参数调优是必不可少的。

痛点背景: 任何技术的默认配置都是为了“普适性”而非“最优性”。如果不了解其核心参数的含义，就无法根据服务器规格和业务负载类型（CPU 密集型 vs. I/O 密集型）进行有效调优，性能提升可能远不及预期。

解决方案: Undertow 的核心调优参数可以通过 Spring Boot 的 application.yml (或 .properties) 文件进行配置。

文件路径: src/main/resources/application.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

server:
  # Undertow 核心配置
  undertow:
    # 核心调优参数
    threads:
      # I/O 线程数，负责处理 I/O 事件。
      # (推荐) 设置为服务器 CPU 核心数。对于 8 核 CPU，这里是 8。
      # 在容器化环境中，注意获取到的是分配给容器的核数。
      io: 8 
      # Worker 线程数，负责执行业务逻辑。
      # 这是最关键的调优参数，其值取决于业务的“阻塞系数”。
      # 计算公式: 线程数 = CPU核心数 * (1 + 平均等待时间 / 平均计算时间)
      # 对于 I/O 密集型应用，这个值可以设置得很大，如 8(核) * 8 = 64 或更高。
      worker: 64
    
    # 缓冲区与连接设置
    # 每个请求的缓冲区大小，对于大请求体或响应体的场景可适当调大。
    buffer-size: 1024 # 单位：字节
    # 是否使用直接内存（堆外内存）作为缓冲区。
    # 对于高流量场景，开启可以减少 GC 压力，提升性能。
    direct-buffers: true
    
    # 其他常见配置
    # 最大 HTTP POST 请求体大小
    max-http-post-size: 2MB
    # 是否启用 HTTP/2
    http2:
      enabled: true

1.5. 高频面试题与陷阱

第二章：现代并发模型对决：虚拟线程 vs. 响应式编程

2.1. 共同的瓶颈：同步阻塞与平台线程

传统 Web 应用性能受限的根源，归结于两点：

1. 编程模型的同步阻塞性: 当代码执行一个 I/O 操作（如 db.query()），执行线程必须暂停，进入 BLOCKED 状态，等待操作完成。
2. 平台线程的高昂成本: Java 线程(java.lang.Thread)与操作系统内核线程是1:1 映射的。内核线程是重量级资源，创建它需要消耗约 1MB 的内存作为线程栈，且其调度切换（上下文切换）会带来显著的 CPU 开销。

这两点结合，导致了一个致命的等式：高并发 I/O 请求 = 大量被阻塞的昂贵平台线程。这必然会迅速耗尽服务器的内存和 CPU 调度能力，造成性能雪崩。

2.2. 方案 A：虚拟线程

核心思想：承认阻塞无法避免，但通过技术手段，将 线程自身的阻塞成本降至接近于零。

工作原理:
虚拟线程解除了 Java 线程与平台线程的 1:1 绑定，引入了 M: N 的调度模型（M 个虚拟线程在 N 个平台线程上运行）。

• 当一个虚拟线程执行阻塞 I/O 操作时，JVM 运行时会检测到这一点，并自动将其从其“载体”平台线程上“卸下”。
• 这个平台线程会立即被释放，去执行另一个准备就绪的虚拟线程。
• 当原 I/O 操作完成后，JVM 会再将那个“睡醒”的虚拟线程调度到任意一个空闲的平台线程上 挂载，继续执行。

整个过程对开发者透明。从代码上看，一切依旧是同步阻塞的写法，但底层平台线程的利用率得到了极大提升。

2.3. 方案 B：响应式编程

核心思想：通过一套完整的异步(Reactive / WebFlux)非阻塞调用链，从编程范式上彻底杜绝线程阻塞。

工作原理:
响应式编程基于 事件循环 (Event Loop) 模型。系统启动少量（通常等于 CPU 核心数）的事件循环线程。

• 一个请求到来，事件循环线程接收它，并开始处理。当遇到 I/O 操作（如查询数据库），它不会等待，而是向底层非阻塞驱动（如 Netty、R2DBC）注册一个“回调(Callback)”，然后立即释放，去处理下一个事件。
• 当 I/O 操作完成，底层驱动会产生一个完成事件，并将其放入事件队列。
• 某个空闲的事件循环线程会从队列中取出该事件，并执行之前注册的回调，继续处理请求的下一阶段。

在这个模型中，线程永远在处理就绪的任务，从不等待。

关键代价:

• 侵入式编程模型: 开发者必须放弃同步写法，使用一套全新的、基于 `Mono` 和 `Flux` 的函数式、声明式 API 来编排整个业务流程。
• 生态依赖: 整个调用链都必须是响应式的。任何一个环节使用了传统阻塞库，都会“污染”并严重破坏事件循环线程的性能。
• 调试复杂度: 代码执行流程非线性，出现错误时，堆栈信息往往是响应式框架的内部调度逻辑，难以定位到具体的业务代码。

对于价值层面来说，WebFlux 之所以没有纳入我们的课程讲解的路线，也正是因为这三个代价，为了追求提升不足 5%的性能，而全面的推翻了我们以往的编码方案，并不推荐。

第三章：GraalVM 原生编译核心原理

3.1. 背景：JVM 在云原生环境下的瓶颈

在前两章中，我们已经分别从 I/O 引擎和并发模型两个层面，对应用性能进行了深度优化。然而，即便拥有了最高效的代码执行策略，承载应用的运行时环境——JVM 本身，在追求极致效率的云原生时代，其固有的设计特性正逐渐成为新的、也是更根本的性能瓶颈。

3.1.1. 启动延时

JVM 的“一次编译，到处运行”依赖于一个动态的运行时环境。当应用启动时，JVM 必须执行一系列重量级操作：加载数千个类的字节码、进行严谨的字节码校验、解释执行初始化代码，并通过 JIT（Just-in-Time）编译器在运行时分析热点代码，再将其编译为高度优化的本地机器码。这一系列过程导致一个典型的 Spring Boot 应用启动耗时通常在 数秒至数十秒 之间。在要求快速弹性伸缩的 Kubernetes HPA 或按需计费的 Serverless 场景中，这种秒级的冷启动延迟是不可接受的，它直接影响了系统的响应速度和资源利用效率。

3.1.2. 内存开销

传统 Java 应用的高内存占用并非完全由业务对象的堆内存（Heap）导致。JVM 自身就是一个复杂的进程，它需要为存储类元数据的 元空间（Metaspace）、JIT 编译器存放优化代码的 代码缓存（Code Cache） 以及垃圾回收器等组件预留大量内存。因此，一个功能极简的应用，其常驻内存（RSS）也常常超过 数百兆字节。在追求高密度部署的容器化环境中，这意味着每个节点能承载的实例数量锐减，直接推高了云基础设施的运营成本。

3.1.3. 打包体积

为保证跨平台兼容性，标准的 Java 应用部署单元（Fat JAR）必须与一个完整的 Java 运行时环境（JRE）一同打包进容器镜像。一个功能齐全的 JRE 本身就相当庞大。这导致一个简单的 Web 应用，其最终的 Docker 镜像体积轻松达到 数百兆字节。臃肿的镜像不仅增加了企业的存储成本，更严重拖慢了 CI/CD 流水线中的镜像分发和部署速度，在网络受限的边缘计算节点上，这一问题尤为突出。

3.2. 核心理论：“封闭世界”假设

为从根本上解决 JVM 的上述瓶颈，GraalVM Native Image 并未选择在原有基础上进行修补，而是引入了一种颠覆性的编译哲学。这一哲学的基石，便是“封闭世界”假设。

3.2.1. JVM 的“开放世界”模型

传统 JVM 是基于“开放世界”模型设计的。这意味着 JVM 允许并支持在 运行时 发生动态变化。其关键特性包括：

• 动态类加载: 应用程序可以通过 ClassLoader 在运行时加载新的 .class 文件。
• 反射 (Reflection): 能够在运行时检查、创建和操作类、方法、字段，即使它们在编译时是未知的。
• 动态代理: 可以在内存中动态生成代理类。

这种高度的灵活性是 Java 生态强大的原因之一，但其代价是，编译器在构建应用时，无法预知程序在运行时的所有可能行为。因此，大量的优化工作必须推迟到运行时，由 JIT 编译器来完成。

3.2.2. GraalVM 的“封闭世界”假设

GraalVM 原生编译则反其道而行之，它基于一个根本性的 “封闭世界”假设。该假设的核心是：

在构建原生可执行文件的那一刻，应用程序在整个生命周期中可能执行到的所有代码、依赖的所有资源，都已完全确定且可知。

这个假设将整个应用程序（包括其所有依赖库和 JDK 模块）视为一个静态的、封闭的集合。编译器可以进行全局的、彻底的静态分析，因为它确信在运行时不会有任何预料之外的新代码被加载或生成。这使得在编译阶段进行彻底的预先优化（Ahead-of-Time, AOT）成为可能。

3.3. 构建流程核心：静态可达性分析

基于“封闭世界”这一核心假设，native-image 构建工具得以执行其最关键的操作：静态可达性分析。此过程是实现原生镜像极致精简的根本手段，它精确地描绘出应用程序在运行时真正需要的代码版图。

3.3.1. 分析起点

静态分析并非凭空开始，它必须从一组明确定义的入口点出发，这些入口点构成了程序执行的最初源头。对于一个典型的 Spring Boot 应用，这些起点包括：

• 主方法: 应用程序的 public static void main(String[] args) 方法。
• 静态初始化块: 所有在分析过程中被发现是“可达”的类的静态初始化代码块 (static {})。
• 框架注册点: 由框架（如 Spring AOT 引擎）在构建时生成的、用于初始化应用上下文和 Bean 的回调函数。
• JNI 调用: 从本地代码（Native Code）调用的 Java 方法。

3.3.2. 图遍历

从上述入口点开始，构建工具会像一个深度优先的爬虫一样，递归地遍历整个应用的调用关系图：

1. 当一个方法被标记为“可达”时，分析器会深入其方法体。
2. 该方法体内引用的所有类、调用的所有其他方法、访问的所有字段，都会被相继标记为“可达”。
3. 这个过程会持续进行，直到所有从入口点可触达的代码路径都被完整地遍历和标记。

最终，这个过程会构建出一个庞大但精确的图谱，包含了应用在运行时可能触及的每一个元素。

3.3.3. 标记与裁剪

图遍历结束后，标记阶段完成。此时，应用 classpath 下的所有代码（包括业务代码、所有依赖库以及 JDK 本身）被清晰地划分为两部分：

• 可达对象: 在图遍历过程中被标记的所有类、方法和字段。
• 不可达对象: 未被标记的其余所有内容。

最后，构建器会执行“裁剪”操作：所有未被标记为“可达”的代码和元数据都将被 彻底丢弃，不会包含在最终生成的原生可执行文件中。

3.4. 运行时环境：Substrate VM (SVM) 解析

静态可达性分析为我们构建了一个精简的代码集，但这引出了一个关键问题：既然最终产物是一个脱离了外部 JRE/JVM 的原生可执行文件，那么像垃圾回收(GC)、线程调度等由 JVM 提供的核心运行时(Runtime)功能，由谁来负责？

答案就是 Substrate VM。

3.4.1. Substrate VM 的角色与定位

Substrate VM (SVM) 并非一个完整的、标准意义上的 JVM，而是一个专门为 GraalVM 原生镜像设计的、极度轻量化的高性能 运行时库。它本身主要使用 Java 的一个子集编写，并被预先编译为本地代码。

其核心定位是：作为原生可执行文件的一部分，在内部提供 Java 程序运行所必需的底层服务，从而彻底取代外部 JVM。

3.4.2. 核心组件

Substrate VM 包含了一系列不可或缺的运行时组件，以支持原生化后的 Java 代码正确执行：

• 内存管理: SVM 内置了一个功能完备的 垃圾回收器(Garbage Collector)。它负责堆内存的分配与回收，支持多种 GC 策略，例如社区版默认提供的、为低内存占用和快速响应优化的 Serial GC。
• 线程调度: 负责管理应用线程的生命周期和调度执行。
• JNI 实现: 提供与本地 C/C++代码交互所需的标准 JNI 接口。
• 异常处理: 实现 Java 语言规范的 try-catch-finally 等异常处理机制。
• 对象模型: 管理对象在内存中的布局、类型信息(RTTI)以及类初始化等。

3.4.3. SVM 的集成方式

Substrate VM 最精妙的设计在于，它自身也完全遵循“封闭世界”假设，并参与到静态可达性分析的过程中。

这意味着，native-image 构建工具在分析你的业务代码时，也会一并分析你的代码实际调用了 Substrate VM 的哪些功能。例如，如果你的应用完全没有使用 JNI，那么 SVM 中与 JNI 相关的组件将被视为“不可达”，并被从最终的可执行文件中裁剪掉。

3.5. 关键优化：构建时初始化

除了通过裁剪代码和运行时来减小体积，GraalVM 还采用了一项颠覆性的优化技术，以实现毫秒级的启动速度，即 构建时初始化。

3.5.1. 传统运行时初始化

在标准 JVM 中，一个类的静态初始化代码块 (static {}) 是在运行时、当该类首次被主动使用时才执行的。对于一个大型应用，启动过程中需要初始化成百上千个类，这一系列串行或并行的静态初始化过程，是造成启动延迟的重要因素。

3.5.2. GraalVM 的构建时初始化流程

GraalVM 打破了这一常规，允许在 native-image 的 构建阶段 就提前执行那些被标记为安全的类的静态初始化块。

1. 构建工具在一个临时的“构建时 JVM”环境中，加载并执行目标类的 static {} 代码块。
2. 执行完毕后，这些类在内存中的完整状态，包括所有静态字段的最终值，会被完整地“快照”下来。
3. 这份内存快照被固化到最终原生可执行文件的一个特殊数据段中，称为 “镜像堆”。

3.5.3. 启动时的效果

当用户执行原生应用时，操作系统会直接将镜像堆数据段从可执行文件中加载并映射到进程的内存空间。这意味着，应用启动时，相关的类就已经处于“已初始化”的状态，完全跳过了执行静态代码块的步骤，从而极大地缩短了启动时间。

3.6. 核心挑战：处理 Java 的动态特性

“构建时初始化”的强大威力，再次凸显了“封闭世界”假设的重要性。然而，正是这个假设，与 Java 语言根深蒂固的动态特性产生了直接冲突。静态 AOT 编译器在面对依赖运行时信息的语言特性时，会无法预知其行为。

这些核心挑战特性包括：

• 反射: Class.forName("com.example.MyClass") 中的类名字符串，在编译时无法确定。
• 动态代理: Proxy.newProxyInstance(...) 在运行时动态生成类。
• JNI (Java Native Interface): 从 Java 代码到本地 C/C++代码的调用，其关联性在编译时难以完全静态分析。
• 资源加载: 通过 ClassLoader.getResourceAsStream("config.xml") 加载资源，路径是动态的。

如果不对这些动态调用进行特殊处理，静态可达性分析将会遗漏它们所引用的目标代码，导致这些代码被错误地裁剪掉，最终在原生应用运行时抛出 ClassNotFoundException 或 NoSuchMethodError 等致命错误。

3.7. Spring AOT 引擎工作机制

手动处理一个大型框架（如 Spring）中所有的动态调用是不现实的。为此，Spring Boot 3 引入了全新的 AOT 引擎，作为框架与 GraalVM 原生编译器之间的关键桥梁。

3.7.1. 触发时机与目标

Spring AOT 引擎并非一个运行时组件，而是一个在 构建时 由构建工具插件（如 spring-boot-maven-plugin 的 process-aot 目标）触发的分析工具。它的核心目标是：分析 Spring 应用，并为 GraalVM 生成所有必需的元数据，以弥合动态特性带来的鸿沟。

3.7.2. 核心工作流程

1. 构建时上下文分析: AOT 引擎会在一个特殊的“模拟”环境中，提前初始化 Spring 的应用上下文(ApplicationContext)。
2. Bean 定义扫描: 它会扫描所有的 Bean 定义、依赖注入关系、@Configuration 类以及其他 Spring 注解。
3. 动态行为预测: 基于上述分析，AOT 引擎能够精确地预测出 Spring 框架在实际运行时，会在哪些地方、以何种方式使用反射来创建 Bean、注入依赖，或者在何处生成 AOP 动态代理等。
4. 元数据生成: 最终，它将所有这些预测出的动态行为，翻译成 GraalVM 能够理解的、格式化的 可达性元数据 配置文件。

3.8. 可达性元数据详解

Spring AOT 引擎的最终产物，就是一系列遵循 GraalVM 规范的 JSON 配置文件，这些文件统称为“可达性元数据”。它们相当于一份给 native-image 编译器的详尽“操作说明书”。

这些配置文件通常位于 META-INF/native-image/ 目录下，主要包括：

• reflect-config.json: 声明了哪些类、方法、字段需要通过反射进行访问。这是最核心和最常见的元数据。
• proxy-config.json: 列出了哪些接口需要被动态代理。
• resource-config.json: 通过正则表达式等模式，声明了哪些资源文件（如 .properties, .xml, .html）需要被打包进原生镜像。
• jni-config.json: 声明 JNI 调用相关的配置。
• serialization-config.json: 声明需要序列化和反序列化的类。

第四章：[实战] 原生镜像构建全流程 (Windows 版)

4.1. [实战] Windows 环境配置与项目初始化

在 Windows 上进行原生编译，比在 Linux/macOS 上多一个关键的前置步骤：安装 C++构建工具。我们将一步步完成所有配置。

4.1.1. 核心依赖清单 (Windows)

1. Visual Studio 2022 Community: 提供 native-image 所必需的 C++编译器和链接器。
2. GraalVM for JDK 21+ (Windows ZIP): 原生编译器的基础。
3. Maven 3.8+: 项目构建工具。
4. Docker Desktop for Windows: 需启用 WSL 2 后端，用于构建 Linux 容器。

4.1.2. 步骤一：安装 Visual Studio C++构建环境

这是在 Windows 上进行原生编译的 强制性前置条件。

1. 访问 Visual Studio 官网，下载并运行 Visual Studio Community 2022 的安装程序。
2. 在“工作负载”选择界面，勾选 “使用 C++的桌面开发”。
3. 在右侧的“安装详细信息”中，确保已勾选“MSVC v143… x64/x86 生成工具”和 “Windows 11/10 SDK”。
4. 点击“安装”并等待完成。

4.1.3. 步骤二：安装与配置 GraalVM

1. 访问 GraalVM For JDK 21 GitHub Releases，下载最新的 graalvm-community-jdk-21.x.x_windows-x64_bin.zip 文件。
2. 将下载的 ZIP 文件解压到一个无中文、无空格的稳定路径，例如 E:\Java\graalvm-community-openjdk-21.0.2+13.1。
3. 配置环境变量：
   • 在 Windows 搜索中输入“编辑系统环境变量”并打开。
   • 点击“环境变量…”。
   • 在“系统变量”中，新建一个变量 JAVA_HOME，值为您解压的路径 E:\Java\graalvm-community-openjdk-21.0.2+13.1。
   • 找到并编辑 Path 变量，在列表顶部新建一条记录 %JAVA_HOME%\bin。
4. 打开一个新的命令提示符(cmd.exe)或 PowerShell 窗口，验证安装：

   1 2 3 4 5 6 7 8 9

   # 验证Java版本 java -version # 预期输出应包含 "OpenJDK Runtime Environment GraalVM CE" # 安装native-image构建工具 gu install native-image # 验证native-image工具 native-image --version

4.1.4. 步骤三：初始化 Spring Boot 项目

这一步与平台无关，操作与之前一致。请在 start.spring.io 上创建一个包含 Spring Web 和 GraalVM Native Support 的 Spring Boot 3.3+ (Java 21) Maven 项目。

4.2. [实战] Windows 本地原生编译与测试

环境就绪后，我们开始在 Windows 上直接编译出 .exe 可执行文件。

4.2.1. 执行原生编译

打开 x64 Native Tools Command Prompt，进入项目根目录，执行：

1
2

# 使用mvnw.cmd脚本，并激活native profile
mvnw.cmd -Pnative native:compile

编译成功后，target\ 目录下会生成一个与您 artifactId 同名的 .exe 文件，例如 demo.exe。

4.2.2. 运行与验证

直接执行这个 .exe 文件来启动应用：

1

target\demo.exe

应用启动后，打开浏览器访问 http://localhost:8080/hello (或其他您定义的接口)进行验证。

4.2.3. 执行原生测试

在原生模式下运行测试：

1

mvnw.cmd -PnativeTest test

4.3. [实战] 在 Windows 上构建 Linux 容器 (Buildpacks)

我们的开发环境是 Windows，但绝大多数生产环境是 Linux。Docker Desktop for Windows 集成的 WSL 2 后端，让我们可以在 Windows 上无缝地构建和运行标准的 Linux 容器。

4.3.1. Buildpacks 简介

Spring Boot 集成的 Cloud Native Buildpacks 是一个智能工具，它能自动将您的应用打包成一个优化的、安全的 Linux 容器镜像，无需您编写 Dockerfile。

4.3.2. 执行构建

在项目根目录执行以下命令：

1
2

# 注意：此命令会在您的Windows机器上，构建一个Linux容器镜像
mvnw.cmd spring-boot:build-image -Dspring-boot.build-image.imageName=your-dockerhub-id/my-app:v1.0.0

4.3.3. 运行 Linux 容器

构建完成后，Docker Desktop 中会新增一个镜像。您可以使用标准 docker 命令运行这个 Linux 容器：

1

docker run -p 8080:8080 your-dockerhub-id/my-app:v1.0.0

4.4. [实战] 进阶：使用 Dockerfile 构建 Linux 容器

当需要对构建过程和基础镜像进行精细控制时，我们采用多阶段 Dockerfile。

4.4.1. 多阶段构建原理

我们将在 Windows 上使用 docker build 命令，但 Dockerfile 中描述的所有步骤，都会在 Docker 引擎的 Linux 虚拟机（WSL 2）中执行。

1. builder 阶段: 使用一个包含 GraalVM 的 Linux 镜像，编译生成 Linux 平台下的原生可执行文件。
2. runtime 阶段: 使用一个极度精简的 distroless Linux 镜像，仅复制 builder 阶段的编译产物。

4.4.2. 编写 Dockerfile

Dockerfile 内容与上一版相同，因为它描述的是 目标 Linux 环境 的构建过程。
文件路径: Dockerfile

1
2
3
4
5
6
7
8
9
10
11
12

# ---- Builder Stage (在Linux环境中执行) ----
FROM ghcr.io/graalvm/native-image-community:21-ol9 as builder
WORKDIR /app
COPY . .
RUN ./mvnw -Pnative native:compile

# ---- Runtime Stage (最终的Linux运行环境) ----
FROM gcr.io/distroless/base-debian11
WORKDIR /app
COPY --from=builder /app/target/demo .
EXPOSE 8080
ENTRYPOINT ["./demo"]

4.4.3. 构建与运行

在 Windows 的项目根目录，打开终端执行：

1

docker build -t your-dockerhub-id/my-app:v1.0.0-dockerfile .

4.5. [实战] 使用 Docker Buildx 进行多平台构建

我们可以在 Windows (AMD64)主机上，为云端常见的多种 Linux 平台（如 linux/amd64 和 linux/arm64）构建镜像。

4.5.1. Docker Buildx 简介与配置

buildx 是 Docker 的插件，用于执行多平台构建。首先，确保它已启用并创建一个构建器实例。

1
2
3

# 创建并使用一个新的构建器实例
docker buildx create --name mybuilder --use
docker buildx inspect --bootstrap

4.5.2. 执行多平台构建

该命令将在您的 Windows 机器上，利用 QEMU 模拟，分别为 linux/amd64 和 linux/arm64 架构编译和打包镜像，并将结果推送至镜像仓库。

1
2
3
4
5

docker buildx build ^
  --platform linux/amd64,linux/arm64 ^
  -t your-dockerhub-id/my-app:latest ^
  --push ^
  .

• ^ 是 Windows cmd.exe 中的换行符。
• --platform: 指定要构建的目标 Linux 平台列表。
• --push: 必需参数，多平台镜像的 manifest list 必须推送到仓库才能生效。