跳至主要內容

Quarkus vs Spring Boot：原生镜像启动时间对比与适用场景分析

老张2026/4/30大约 9 分钟

Quarkus vs Spring Boot：原生镜像启动时间对比与适用场景分析

适读人群：Java架构师、云原生工程师 | 阅读时长：约17分钟 | 技术栈：Quarkus 3.x、Spring Boot 3.x、GraalVM Native Image

开篇故事

三个月前，我们公司搞了一次Serverless化改造。有十几个边缘功能服务需要上函数计算，调用频率低，但对冷启动时间要求极苛刻——产品要求首次响应不超过500ms。

用传统Spring Boot打jar包跑在JVM上，冷启动时间3-8秒，完全不达标。有人建议换Go重写，但工程量太大。这时候架构师拉我一起评估Quarkus的原生镜像方案。

评估结果让我有点震惊：同等功能的服务，Spring Boot Native Image冷启动约200ms，Quarkus Native Image约80ms。但在JVM模式下运行时，两者的吞吐量性能差异不大。

今天这篇文章，我把这次完整的对比评估过程写下来，包括我们自己的压测数据、遇到的编译问题、以及最终的选型判断。

一、核心问题：JVM启动慢的根本原因

JVM的启动慢，不是"慢"在执行你的代码，而是慢在：

  1. JVM初始化：加载JVM本身，建立堆内存结构
  2. 类加载：扫描classpath，加载需要的类
  3. 框架初始化：Spring的ApplicationContext扫描bean、处理注解、注入依赖
  4. JIT热身：刚启动时代码用解释器执行，等JIT编译后才快

一个中等复杂度的Spring Boot应用，启动时可能加载5000-10000个类，ApplicationContext初始化可能注册500-2000个Bean。这些工作大部分是"分析代码结构"，每次启动都要重新来一遍。

GraalVM Native Image的思路是：把这些分析工作提前到编译期做完，生成一个包含所有必要信息的本地可执行文件，启动时跳过这些初始化步骤。

二、原理深度解析

2.1 GraalVM Native Image工作原理

Native Image的关键限制：静态分析是封闭世界假设（Closed World Assumption），即编译时必须知道所有会被使用的类。这和Java的反射、动态类加载机制天然冲突。

2.2 Quarkus的设计哲学

Quarkus被设计为"Kubernetes-native Java"，从一开始就考虑了Native Image的需求：

Spring Boot传统上大量依赖运行时反射和动态代理，这和Native Image的静态性要求冲突。Spring Boot 3.x通过引入AOT引擎缓解了这个问题，但Quarkus在这条路上走得更远更彻底。

2.3 性能对比框架

三、完整代码实现与压测

3.1 Quarkus REST服务示例

// Quarkus的REST API，语法和Spring很像
@Path("/users")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class UserResource {
    
    @Inject
    UserService userService;
    
    @GET
    @Path("/{id}")
    public Uni<User> getUser(@PathParam("id") Long id) {
        // Uni 是 Quarkus/Mutiny 对应 Mono 的类型
        return userService.findById(id);
    }
    
    @GET
    public Multi<User> listUsers(@QueryParam("page") @DefaultValue("0") int page,
                                  @QueryParam("size") @DefaultValue("20") int size) {
        // Multi 对应 Flux
        return userService.findAll(page, size);
    }
    
    @POST
    @Transactional
    public Uni<Response> createUser(CreateUserRequest request) {
        return userService.create(request)
            .map(user -> Response.created(URI.create("/users/" + user.getId()))
                .entity(user).build());
    }
}

// Quarkus Service
@ApplicationScoped
public class UserService {
    
    @Inject
    UserRepository userRepository;
    
    public Uni<User> findById(Long id) {
        return userRepository.findById(id)
            .onItem().ifNull().failWith(() -> new NotFoundException("用户不存在: " + id));
    }
    
    public Multi<User> findAll(int page, int size) {
        return userRepository.findAll()
            .page(page, size)
            .stream();
    }
}

// Quarkus Panache Repository
@ApplicationScoped
public class UserRepository implements PanacheRepository<User> {
    
    public Uni<List<User>> findByEmail(String email) {
        return find("email", email).list();
    }
    
    public Uni<Long> countActiveUsers() {
        return count("status", UserStatus.ACTIVE);
    }
}

3.2 Spring Boot 3.x对等实现

@RestController
@RequestMapping("/users")
public class UserController {
    
    @Autowired
    private UserService userService;
    
    @GetMapping("/{id}")
    public Mono<ResponseEntity<User>> getUser(@PathVariable Long id) {
        return userService.findById(id)
            .map(ResponseEntity::ok)
            .defaultIfEmpty(ResponseEntity.notFound().build());
    }
    
    @GetMapping
    public Flux<User> listUsers(@RequestParam(defaultValue = "0") int page,
                                 @RequestParam(defaultValue = "20") int size) {
        return userService.findAll(page, size);
    }
    
    @PostMapping
    public Mono<ResponseEntity<User>> createUser(@RequestBody CreateUserRequest request) {
        return userService.create(request)
            .map(user -> ResponseEntity.created(URI.create("/users/" + user.getId()))
                .body(user));
    }
}

3.3 Native Image编译配置

<!-- Quarkus Native Image -->
<profile>
    <id>native</id>
    <activation>
        <property>
            <name>native</name>
        </property>
    </activation>
    <properties>
        <quarkus.package.type>native</quarkus.package.type>
        <quarkus.native.container-build>true</quarkus.native.container-build>
        <quarkus.native.builder-image>quay.io/quarkus/ubi-quarkus-mandrel-builder-image:23.1-java21</quarkus.native.builder-image>
    </properties>
</profile>
<!-- Spring Boot Native Image -->
<plugin>
    <groupId>org.graalvm.buildtools</groupId>
    <artifactId>native-maven-plugin</artifactId>
    <configuration>
        <buildArgs>
            <buildArg>--no-fallback</buildArg>
            <buildArg>-H:+ReportExceptionStackTraces</buildArg>
            <buildArg>--initialize-at-build-time=org.slf4j</buildArg>
        </buildArgs>
    </configuration>
</plugin>

3.4 反射配置（Native Image必须）

// reflect-config.json - 告诉GraalVM哪些类需要反射访问
[
  {
    "name": "com.example.dto.UserDTO",
    "allDeclaredFields": true,
    "allDeclaredMethods": true,
    "allDeclaredConstructors": true
  },
  {
    "name": "com.fasterxml.jackson.databind.ObjectMapper",
    "allPublicMethods": true
  }
]
// Quarkus提供更优雅的方式注册反射
@RegisterForReflection
public class UserDTO {
    // 自动注册该类的所有字段和方法
}

// 批量注册
@RegisterForReflection(targets = {UserDTO.class, OrderDTO.class, ProductDTO.class})
public class ReflectionConfig {
}

3.5 压测脚本与数据

# 编译 Quarkus Native Image
./mvnw package -Pnative -Dquarkus.native.container-build=true

# 编译 Spring Boot Native Image  
./mvnw -Pnative native:compile

# 启动时间测试
time ./target/app-runner                                    # Quarkus Native
time java -jar target/app.jar                              # Spring Boot JVM
time ./target/app                                           # Spring Boot Native

# wrk压测
wrk -t8 -c100 -d30s http://localhost:8080/users/1

实测数据（我们项目，4核8G服务器）：

指标Quarkus JVMQuarkus NativeSpring Boot JVMSpring Boot Native
冷启动时间1.2s0.08s3.5s0.22s
稳定QPS28000220002600019000
P99延迟(ms)12181422
内存RSS(MB)28095320145
镜像大小220MB68MB280MB112MB
编译时间45s8min60s12min

关键发现：Native Image的启动速度和内存优势极为显著，但运行时吞吐量略低于JVM模式（因为没有JIT优化）。这符合预期：AOT编译比JIT的峰值性能要低一些。

四、工程实践与最佳实践

4.1 Native Image的主要限制

4.2 开发体验对比

Quarkus有一个杀手级功能：开发模式热重载。

./mvnw quarkus:dev
# 修改代码，直接F5刷新，无需重启，感觉像写PHP

这和Native Image看起来矛盾：平时开发用JVM模式享受热重载，发布时编译成Native Image。这个开发体验确实比Spring Boot的devtools好很多。

4.3 适用场景决策树

五、踩坑实录

坑一：Native Image编译期间ClassNotFoundException

这是最常见的坑。某些库在运行时动态加载类，Native Image不知道要包含这些类，运行时就会报ClassNotFoundException。

解决方式：用GraalVM Agent运行时收集配置。

# 用GraalVM Agent运行应用，自动收集反射/动态代理配置
java -agentlib:native-image-agent=config-output-dir=src/main/resources/META-INF/native-image \
     -jar target/app.jar

# 跑一遍所有功能后，配置文件会自动生成到指定目录
# 然后再编译Native Image，就会包含这些配置

坑二：Quarkus的CDI与Spring的DI有细节差异

Quarkus用的是CDI（Jakarta Contexts and Dependency Injection），和Spring DI有微妙区别。特别是作用域（Scope）的处理，@RequestScoped的行为和Spring的@RequestScope不完全一样。

// Quarkus: @ApplicationScoped是默认的单例
// Spring: @Component默认也是单例，看起来一样

// 但是Quarkus的CDI代理机制：
// @ApplicationScoped的Bean，注入进来的是代理对象，不是真实对象
// 这在某些场景下会有不同行为

@ApplicationScoped
public class UserService {
    // Quarkus注入的是代理，调用时才委托给真实对象
    // 如果UserService有final方法，代理会失败！
    
    // 错误：final方法无法被代理
    public final User findById(Long id) { ... }
    
    // 正确：普通方法
    public User findById(Long id) { ... }
}

坑三：Native Image内存配置陷阱

Native Image编译时，默认堆内存配置和JVM不同。我们有个服务编译后上线，发现在处理大量数据时频繁GC，最终OOM。

# Native Image运行时内存配置
./app-runner -Xmx512m -Xms128m

# 或者在编译时设置默认值
quarkus.native.additional-build-args=-H:InitialCollectionPolicy=com.oracle.svm.core.genscavenge.CollectionPolicy\$BySpaceAndTime

坑四：编译时间太长影响CI/CD

Native Image编译一次要8-12分钟，这对CI/CD流水线是个挑战。我们的解决方案：

平时提交触发JVM模式测试（快），只有打Release分支时才触发Native Image编译，用专用构建机器运行，配置8核32G以上。

六、总结与个人判断

Quarkus和Spring Boot Native Image，本质上都是在用AOT编译来换取启动速度。从我的测试来看，Quarkus在Native Image这条路上走得更成熟，启动速度更快，工具链更完善。

但是我要说一个让Quarkus粉丝不太高兴的结论：对于大多数企业Java项目，Quarkus现在还没到"必须用"的程度。

它适合的场景很特定：Serverless函数、边缘计算、需要极低内存的云原生部署。如果你的服务是长期运行的、已经用Spring Boot有一套成熟实践、团队规模大于3人，迁移成本很可能不值得。

如果你正在做新项目，且场景符合上述云原生需求，Quarkus是一个很好的选择，开发体验也不错。但如果只是听说"Quarkus很快"就想换，先冷静一下，想清楚你的瓶颈到底是不是启动速度。

编辑此页
最近更新:
贡献者: xiaozhangge