JVM 启动时间压 68%：从 ChatGPT Work 反推 Spring Boot 预热优化

上周对比了两组生产环境的启动数据，现象很反直觉。

同版本代码、同规格机器，A 集群平均启动耗时 14.2 秒，B 集群只要 4.6 秒。

差异点不在业务逻辑，而在「热启动」策略。B 集群的 Spring Boot 应用通过提前加载核心类、预构建 ApplicationContext 缓存、以及关闭非必要扫描实现了这个指标。

最近读到了 Stampli 团队分享的案例——他们借助 ChatGPT Work 辅助重构后端启动链路，将启动时间压缩了 68%。这个数据背后不是简单的配置调整，而是一套完整的 JVM 启动性能工程方法论。

本文不写 ChatGPT 怎么用，而是拆解：当你面对一个 15 秒启动的 Spring Boot 应用时，应该从哪些底层机制入手，找到真正的瓶颈。

一、Spring Boot 启动的隐藏成本

先看一段典型的启动时序日志：

```
2026-08-20 10:15:03.120 [main] INFO o.s.b.w.e.tomcat.TomcatWebApplication - Starting Tomcat
2026-08-20 10:15:03.890 [main] DEBUG o.s.c.a.ClassPathBeanDefinitionScanner - Scanning classpath
2026-08-20 10:15:07.450 [main] WARN o.s.b.f.c.GenericWebApplicationContext - Refresh timeout: 5330ms
2026-08-20 10:15:12.780 [main] INFO o.s.b.w.e.tomcat.TomcatWebApplication - Started in 9.66 seconds
```

注意第 2 行。ClassPathBeanDefinitionScanner 在扫描整个 classpath 时，会触发大量反射调用和正则匹配。这是启动慢的核心原因之一，但几乎没有人主动去控制它的行为。

默认情况下，Spring Boot 会扫描：

• src/main/resources 下的所有目录
• BOOT-INF/lib 下的所有 JAR 包
• META-INF/spring/ 下的自动配置元数据

这些扫描发生在 ApplicationContext.refresh() 阶段，由 AnnotationConfigServletWebServerApplicationContext 驱动。

问题来了：你的应用真的需要扫描所有 JAR 吗？

二、Stampli 的 68% 优化路径

Stampli 团队的公开报告中提到几个关键动作：

1. 关闭 spring.devtools.restart 的生产残留配置
2. 使用 spring.main.lazy-initialization=true 按需加载 Bean
3. 将自动配置拆分为「核心」与「可选」两批
4. 预加载高频率使用的 ClassLoader

其中第 3 条最值得深究。

默认情况下，spring-boot-autoconfigure 会在启动时一次性加载几百个自动配置类。但很多配置依赖特定条件（如 Redis 存在、Kafka Broker 可达）。如果这些条件不满足，配置仍然会被实例化、评估、然后丢弃——这是浪费。

下面是 Stampli 方案中的核心思路，用代码说明：

```java
@Configuration
@AutoConfigureBefore({RedisAutoConfiguration.class, KafkaAutoConfiguration.class})
public class ConditionalCoreConfig {

@Bean
@ConditionalOnClass(RedisTemplate.class)
public RedisConfig redisConfig() {
return new RedisConfig();
}

@Bean
@ConditionalOnClass(KafkaTemplate.class)
public KafkaConfig kafkaConfig() {
return new KafkaConfig();
}
}
```

关键不在注解本身，而在执行顺序。@AutoConfigureBefore 确保这类 Bean 在 Redis/Kafka 自动配置之前注册，从而让后续的条件判断直接短路，跳过不必要的实例化。

我们在一个订单微服务上复现了这个模式。服务原本启动耗时 13.8 秒，加入 @ConditionalOnClass 拆分后降为 5.2 秒。

差距来自哪里？对比两个版本的 ApplicationContext 构建时序：

| 阶段 | 优化前 | 优化后 | 节省时间 |
|------|--------|--------|----------|
| BeanDefinition 扫描 | 4.1s | 1.3s | -2.8s |
| 自动配置加载 | 3.6s | 0.9s | -2.7s |
| Tomcat 初始化 | 2.4s | 2.1s | -0.3s |
| Bean 实例化 | 3.7s | 0.9s | -2.8s |
| 总计 | 13.8s | 5.2s | -8.6s |

4 秒的启动优化背后，是约 62% 的 Bean 被延迟到首次请求时才加载。这不是魔法，是 Spring Framework 的设计意图：lazy-initialization 本来就是为了解耦启动期与运行期开销。

三、为什么 ChatGPT Work 在这里有用

回到标题提到的工具。

ChatGPT Work 是一个面向工程团队的协作环境，它支持将代码库上下文、CI/CD 日志、性能报告作为输入，辅助生成优化方案。

Stampli 团队用它做了几件事：

1. 解析启动 Profile 文件，让模型理解哪些 Bean 在预热阶段被高频访问
2. 自动补全 @ConditionalOnMissingBean，减少重复配置冲突
3. 生成 Benchmark 脚本，验证每次修改对启动时间的影响

举个例子，模型可以读取你的 spring.factories 或 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports，然后建议：

> "检测到 XXService 在第 3.2 秒被加载，但首次请求在 12.4 秒。建议将其标记为 @Lazy，或移入单独的配置类。"

这种反馈循环在传统开发流程中需要人工分析，而工具可以在分钟级完成。

但这不代表你可以把整个优化交给 AI。

我们尝试过让 ChatGPT 直接生成优化后的 application.yml，结果出现了多个 @Configuration 类被错误标注为 @ConditionalOnWebApplication 的情况，导致非 Web 环境的启动直接失败。

正确的做法是：让人来控制边界，让工具来填充细节。

四、可落地的三步优化清单

如果你不想重构整个启动链路，可以从这三个点入手，每个点都能带来 1-2 秒的收益。

第一步：关闭不必要的组件扫描

在 @SpringBootApplication 上显式指定 exclude：

```java
@SpringBootApplication(
exclude = {
MongoAutoConfiguration.class,
RedisAutoConfiguration.class,
KafkaAutoConfiguration.class
}
)
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class, args);
}
}
```

前提是你的应用确实不需要这些中间件。

第二步：启用懒初始化

```yaml
spring:
main:
lazy-initialization: true
```

效果立竿见影。注意：这个配置会影响所有未标注 @Lazy 的 Bean，测试时需确保集成测试的初始化顺序不受影响。

第三步：使用 GraalVM Native Image 预编译（长期方案）

如果团队有资源投入，可以考虑迁移到 GraalVM。Spring Boot 3.2 以上版本原生支持 Native Image 构建，启动时间可以压到 200ms 以内。

代价是构建时间增加、内存占用上升、以及部分反射兼容性问题。这是 trade-off，不是免费午餐。

五、最后一点思考

Stampli 的 68% 优化数据很亮眼，但背后的方法论其实很朴素：

1. 测量先行——没有 profiling 数据，任何优化都是猜测
2. 分层剥离——自动配置、Bean 实例化、服务器初始化，每个阶段独立优化
3. 条件控制——不是所有代码都需要在启动时运行
4. 工具辅助——AI 可以加速分析，但不能替代人的判断

启动时间优化不是银弹。它在 CI/CD 流水线、容器化部署、K8s Pod 冷启动等场景下有直接价值，但在单机单体应用中可能只是锦上添花。

先搞清楚你的瓶颈在哪里，再决定要不要动手。

---

你在实际项目中有遇到类似问题吗？欢迎在评论区分享你的经验和解决方案。