17.4 启动流程定制与启动优化

在绝大多数项目里，Spring Boot 的默认启动行为已经足够好用。但随着系统规模增长、部署环境多样化（容器化、Serverless），启动速度逐渐成为影响交付体验和资源成本的关键指标。掌握启动流程的定制方法，可以在不破坏原有设计的前提下获取必要的控制权；而针对性地做启动优化，则能让应用在几秒甚至毫秒级完成就绪。

17.4.1 理解启动流程的可干预点

回顾第14章，Spring Boot 启动的核心由 SpringApplication.run() 驱动，其执行过程可以概括为以下几个阶段：

1. 准备环境 —— 构建 ApplicationContext，加载 Environment（属性源、Profile 等）。
2. 创建并刷新容器 —— 加载 Bean 定义、执行自动配置、完成依赖注入。
3. 回调与就绪 —— 调用 CommandLineRunner 和 ApplicationRunner，广播 ApplicationReadyEvent。

在每个阶段，Spring Boot 都预留了扩展点，让开发者能插入自定义逻辑，而不是去改变底层源码。

17.4.2 定制启动行为的常用手段

1. 监听启动生命周期事件

Spring Boot 在启动过程中会发布一系列事件，所有继承自 SpringApplicationEvent 的类都可以被监听。常见的有：

| 事件 | 时机 | 典型用途 |
| :--- | :--- | :--- |
| ApplicationStartingEvent | SpringApplication 刚创建，Environment 尚未准备好 | 极早期的配置，如注册自定义 ApplicationContextInitializer |
| ApplicationEnvironmentPreparedEvent | Environment 构建完毕，但上下文尚未创建 | 基于环境变量或 Profile 动态调整配置源 |
| ApplicationContextInitializedEvent | ApplicationContext 创建完毕，Bean 定义尚未加载 | 向容器注册特定的 Bean 定义 |
| ApplicationPreparedEvent | 容器刷新之前，此时 Bean 定义已加载完毕 | 修改或移除特定的自动配置类 |
| ApplicationStartedEvent | 容器刷新完成，但 CommandLineRunner 等尚未执行 | 记录启动完成时刻，或启动某些后台任务 |
| ApplicationReadyEvent | 所有 CommandLineRunner 等执行完毕，应用完全就绪 | 发送“服务可用”信号，或做健康检查预热 |
| ApplicationFailedEvent | 启动过程中发生异常 | 记录异常、发送报警或执行清理 |

监听方式很简单，直接用 @EventListener 注解即可：

@Component
public class StartupListener {

    @EventListener(ApplicationStartedEvent.class)
    public void onStarted() {
        System.out.println("容器刷新完成，应用已启动");
    }
}

如果想在事件发布的早期就介入（例如在 Spring Bean 还未初始化时），可以通过 SpringApplication.addListeners() 手动注册非容器托管的监听器。

2. 使用 ApplicationRunner 与 CommandLineRunner

当容器就绪后，如果需要立刻执行一段一次性初始化逻辑（例如预加载字典数据、初始化规则引擎、检测外部依赖可用性），应实现 ApplicationRunner 或 CommandLineRunner 接口。两者功能相似，区别在于参数封装：

@Component
public class DataWarmup implements ApplicationRunner {
    @Override
    public void run(ApplicationArguments args) {
        // 预加载热数据到缓存
        cacheService.loadCommonDict();
    }
}

这两个 Runner 在 ApplicationReadyEvent 发布之前按 @Order 指定的顺序执行，适合做启动后的最后一轮校验或预热。

3. 延迟初始化非核心 Bean

有些 Bean 在启动时就需要执行大量初始化逻辑（比如解析复杂配置、建立远程连接），但实际上并非应用启动后立刻被使用。可以将其标记为 @Lazy，容器会在首次调用时才创建，避免拖慢启动：

@Service
@Lazy
public class ReportEngine {
    // 仅在首次请求报表时初始化
}

也可以在全局配置中开启所有 Bean 的延迟初始化，但因为会隐藏启动时的装配错误（可能运行一段时间后才暴露），通常只建议在明确评估后使用：

spring:
  main:
    lazy-initialization: true

4. 定制 Banner 与启动日志

关闭启动 Banner 可以减少控制台输出，节省极少量启动时间：

SpringApplication app = new SpringApplication(MyApp.class);
app.setBannerMode(Banner.Mode.OFF);
app.run(args);

还可以通过 application.properties 调整启动日志的级别，避免大量 DEBUG/TRACE 信息拖慢启动：

logging.level.org.springframework.boot=INFO

17.4.3 启动优化：从秒级到毫秒级

对于云原生场景，尤其是弹性伸缩、滚动更新、Serverless 冷启动，启动速度直接影响可用性和成本。以下几个方向是实践中效果最显著的优化点。

1. 精简自动配置

Spring Boot 的 @EnableAutoConfiguration 会根据 classpath 下存在的 jar 包自动装配大量组件。很多自动配置可能永远用不到，却消耗了类加载和 Bean 定义时间。可以通过以下方式关闭不必要的配置：

@SpringBootApplication(exclude = {
    DataSourceAutoConfiguration.class,
    MongoAutoConfiguration.class,
    RabbitAutoConfiguration.class
})

或者使用 spring.autoconfigure.exclude 属性批量排除。更精细的做法是在编译阶段剔除不需要的 starter，只保留真正使用的依赖。

2. 使用 JVM 预热与参数调优

• 关闭分代日志：将 GC 日志等级设为 INFO 或直接关闭，避免不必要的 I/O。
• 禁用验证码：对于 Web 应用，在启动时禁用 TLD 扫描可减少扫描开销：server.servlet.register-defaults=false 或 spring.mvc.formcontent.filter.enabled=false（视场景）。
• 合理设置堆大小：避免容器启动时频繁 full GC。

3. 利用 Spring AOT 编译

Spring Framework 6 及 Spring Boot 3 开始深度集成 Ahead-Of-Time 编译。AOT 将原本在运行时执行的步骤（如代理创建、反射调用、条件判断）提前到编译期处理，生成接近静态的初始化代码。使用 Spring Boot 的 AOT 支持，只需简单配置：

• 使用 Maven 插件或 Gradle 插件生成 AOT source，然后打包为本地可执行文件（通过 GraalVM Native Image）或优化后的 JVM 镜像。
• 即便不编译为原生镜像，AOT 的提前计算也能将启动时间缩短 50% 以上。

更详细的 AOT 与原生编译内容会在 17.5 节展开。

4. 类路径瘦身

Spring Boot 应用通常是个 fat jar，里面包含了所有依赖。启动时需要扫描大量的类和资源。使用 spring-boot-thin-launcher 或分层构建工具（如 Docker 分阶段构建），可以将类和依赖分离，减少每次部署的扫描范围。对于容器环境，利用镜像缓存层使依赖层保持稳定，也有助于加速重启后的加载。

5. 监控与分析启动过程

要优化，先要测量。Spring Boot 提供了 ApplicationStartup 接口，可以收集启动步骤的耗时。通过 BufferingApplicationStartup 结合 Actuator 暴露指标，即可定位哪些 Bean 或自动配置耗时最长：

SpringApplication app = new SpringApplication(MyApp.class);
app.setApplicationStartup(new BufferingApplicationStartup(2048));
app.run(args);

之后通过 /actuator/startup 端点查看详细的步骤树，找出瓶颈。

17.4.4 实战建议与权衡

• 启动优化的收益递减：从 10 秒优化到 3 秒通常很容易，但再往下往往会触及类加载瓶颈。此时应评估 AOT 或原生镜像——它们代表着质的提升，但也意味着构建流程与运行时限制（如反射、动态代理的受限使用）需要适配。
• 延迟加载的风险：启用全局惰性加载后，某些隐含的配置错误可能延迟到生产流量访问时才暴露。建议只对明确“可以推迟”的 Bean 使用 @Lazy。
• 定制不要过度：事件监听和 Runner 赋予了开发者极大的控制权，但也要避免在启动阶段做重逻辑，否则反而会抵消优化效果。

掌握启动流程的定制与优化，本质上是为了让应用在正确的时间点做正确的事，而非无节制地“加速”。在生产环境中，一个稳定、可预测的启动流程，往往比极限的冷启动时间更具价值。