Spring Boot启动慢？这5个优化点带你起飞

Spring Boot 启动慢的痛点

作为一名后端开发，日常工作中经常与 Spring Boot 框架打交道。在项目开发初期，Spring Boot 凭借其 “约定优于配置” 的理念，确实极大地提高了开发效率，快速搭建起基础框架。然而，随着项目的不断迭代和功能的持续增加，一个令人头疼的问题逐渐凸显出来 ——Spring Boot 的启动速度越来越慢。

在本地开发环境中，每次修改代码后重启项目，都需要漫长的等待时间。有时候只是修改了一个小功能，想要快速验证效果，却不得不花费数分钟等待项目启动完成，这严重打断了开发思路，降低了开发效率。就好比你在写一篇文章，思路正流畅的时候，却因为电脑反应慢，每次敲几个字都要卡顿一下，极大地影响了创作的连贯性。

在生产环境中，启动慢的问题更是带来了诸多隐患。每次上线新版本，较长的启动时间意味着服务不可用的窗口期变长，这期间可能会影响用户的正常使用，导致业务损失。而且，在一些对服务响应速度要求极高的场景下，如电商大促期间，启动慢可能会成为压垮系统的最后一根稻草，引发连锁反应，造成严重的后果。

曾经参与过一个电商项目，在一次促销活动前夕进行系统升级。由于项目中 Spring Boot 应用启动缓慢，新服务迟迟无法上线，差点错过活动开始时间，幸好及时优化才避免了一场危机。这件事让我深刻认识到，Spring Boot 启动慢绝不是一个可以忽视的小问题，而是关系到开发效率、系统稳定性和业务发展的关键痛点，必须要找到有效的解决办法。

优化点一：减少业务初始化

（一）问题分析

在 Spring Boot 应用启动过程中，业务初始化操作是耗时的重要环节。以数据库连接为例，建立与数据库的连接需要进行网络通信、身份验证以及资源分配等一系列复杂操作。假设我们使用的是 MySQL 数据库，在初始化时，Spring Boot 会根据配置文件中的信息，加载数据库驱动，然后尝试与 MySQL 服务器建立 TCP 连接。这个过程中，如果网络不稳定或者服务器负载较高，连接的建立可能会花费数秒甚至更长时间。

再看 Redis 连接，同样需要进行网络握手、配置参数协商等步骤。当应用程序需要与 Redis 集群进行交互时，初始化过程还包括对集群节点信息的获取和管理，这无疑会进一步增加启动的时间开销。

除了这些外部资源连接，项目中一些复杂的业务逻辑初始化也会带来问题。比如，在一个电商系统中，启动时可能需要加载大量的商品数据到内存缓存中，以提高后续查询的效率。如果商品数据量庞大，这个加载过程会占用大量的 CPU 和内存资源，导致启动速度大幅下降。

（二）优化方案

减少不必要的依赖是优化的关键一步。在项目的依赖管理文件（如 Maven 的 pom.xml 或 Gradle 的 build.gradle）中，仔细检查每个依赖项。有些依赖可能是在开发过程中临时引入用于测试或实验性功能的，但在正式环境中不再需要。例如，在开发阶段，为了方便调试数据库操作，可能引入了一个数据库管理工具的依赖，但在生产环境中，这个依赖并不会被实际使用，就可以将其去除。

对于一些非关键的初始化逻辑，将其改为异步执行能显著加快启动速度。Spring 框架提供了强大的异步支持，使用 @Async 注解可以轻松实现这一目标。首先，在 Spring Boot 的主启动类上添加 @EnableAsync 注解，开启异步功能。然后，在需要异步执行的初始化方法上添加 @Async 注解。比如，在一个邮件发送服务中，启动时可能需要初始化一些邮件模板和配置信息，这些操作并不影响应用的核心功能，可以将其异步化：

import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Service;

@Service
public class EmailService {

    @Async
    public void initEmailConfig() {
        // 模拟邮件配置初始化操作，如加载模板文件、设置邮件服务器地址等
        try {
            Thread.sleep(2000);
            System.out.println("邮件配置初始化完成");
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

这样，在应用启动时，initEmailConfig 方法会被提交到一个异步线程池中执行，主线程不会被阻塞，从而加快了启动速度。

优化点二：延迟初始化

（一）原理介绍

在 Spring Boot 2.2 版本后，引入了一个非常实用的属性 ——spring.main.lazy-initialization。这个属性就像是一个聪明的调度员，它的作用是延迟所有 Bean 的初始化。

在传统的 Spring Boot 启动过程中，就好比一场热闹的聚会，所有宾客（Bean）都会在聚会一开始就全部到场，不管他们是否马上要参与活动。这就导致了在启动时，需要花费大量时间来初始化每一个 Bean，即使有些 Bean 在启动后的很长一段时间内都不会被使用。

而有了 spring.main.lazy-initialization 属性后，情况就大不一样了。它让宾客们（Bean）不再需要在聚会一开始就全部到场，而是等到有需要的时候才过来。这样一来，在启动阶段，就只需要处理那些真正急需的 Bean，大大减少了启动时的工作量，从而加快了启动速度。

（二）实际应用

使用这个优化点非常简单，只需要在 application.yml 文件中添加如下配置：

spring:
  main:
    lazy-initialization: true

配置完成后，Spring Boot 应用在启动时，只会初始化一些必要的基础设施 Bean，而其他业务 Bean 会被延迟初始化。当第一次访问某个需要特定 Bean 的接口或功能时，对应的 Bean 才会被初始化。

需要注意的是，由于这种延迟初始化机制，首次访问某些接口时，可能会因为 Bean 的初始化而导致响应速度变慢，就像聚会中临时邀请宾客，宾客需要时间赶过来一样。但后续的访问就会恢复正常速度，因为 Bean 已经初始化好了。在一个电商项目中，开启延迟初始化后，启动时间从原来的 10 秒缩短到了 6 秒，虽然首次访问商品列表接口时，响应时间增加了 1 秒左右，但在后续的操作中，整体的系统性能并没有受到影响，而启动速度的提升却带来了开发和部署效率的显著提高 。

优化点三：Spring Context Indexer

（一）功能解析

从 Spring5 版本开始，Spring 框架提供了一个非常实用的功能 ——spring-context-indexer。在大型 Spring Boot 项目中，类的数量众多，Spring 在启动时进行类扫描的工作量巨大，这是导致启动缓慢的一个重要原因。就好比在一个大型图书馆里找一本书，如果没有索引，你需要一本本去查找，效率非常低。

spring-context-indexer 的作用就是提前生成 @ComponentScan 的扫描索引，就像给图书馆的书籍制作了详细的索引目录。在项目编译阶段，它会收集所有带有 Spring 模式注解（如 @Component、@Service、@Repository 等）的类信息，并将这些信息记录在一个特定的索引文件中。当 Spring Boot 应用启动执行 @ComponentScan 扫描类时，不再需要遍历整个类路径去查找这些注解类，而是直接读取这个索引文件，快速定位到需要的类，从而大大提高了扫描速度，减少了启动时间。

（二）使用步骤

使用 spring-context-indexer 功能非常简单，首先需要在项目的依赖管理文件中导入相关依赖。如果使用 Maven，在 pom.xml 文件中添加如下依赖：

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context-indexer</artifactId>
    <optional>true</optional>
</dependency>

如果使用 Gradle，在 build.gradle 文件中添加：

annotationProcessor 'org.springframework:spring-context-indexer'

添加依赖后，在 Spring Boot 的启动类上添加 @Indexed 注解：

import org.springframework.context.annotation.Indexed;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@Indexed
@SpringBootApplication
public class YourApplication {
    public static void main(String[] args) {
        SpringApplication.run(YourApplication.class, args);
    }
}

完成上述操作后，重新编译项目。在编译打包之后，会在项目的 META-INT 目录下生成一个 spring.components 文件。这个文件就是索引文件，它记录了项目中所有被 Spring 管理的组件信息。当应用启动时，Spring 会优先读取这个文件，快速完成组件扫描，大大提高启动速度。在一个拥有上千个类的大型电商项目中，使用 spring-context-indexer 后，启动时间缩短了约 30%，效果十分显著 。

优化点四：关闭 JMX

（一）默认设置

在 Spring Boot 2.2.X 版本以下，默认情况下，JMX（Java Management Extensions）是开启的。JMX 是 Java 提供的一套标准 API，它就像是一个全面的监控室，可以用于监控 JVM 状态，如内存使用情况、线程活动、垃圾回收（GC）等，还能管理应用组件，比如启停服务、调整参数等。通过 JMX，我们可以将应用中的组件以 MBean（Managed Bean）的形式暴露出来，方便进行管理和监控 。

（二）关闭方法

如果在项目中不需要使用 JMX 进行监控和管理，那么可以手动将其关闭，这有助于提升 Spring Boot 应用的启动速度。在 application.yml 文件中添加如下配置即可关闭 JMX：

spring:
  jmx:
    enabled: false

关闭 JMX 之所以能提升启动速度，是因为在启动过程中，Spring Boot 不再需要进行与 JMX 相关的初始化操作，如创建 MBeanServer、注册 MBeans 等。这些操作虽然在功能上很强大，但对于一些不需要 JMX 功能的项目来说，却是额外的负担。就好比一辆汽车，原本安装了一些特殊的设备用于专业检测，但如果我们只是日常驾驶，这些设备不仅占用空间，还可能增加启动时的准备时间。关闭 JMX 就像是卸下了这些不必要的设备，让 Spring Boot 应用能够轻装上阵，更快地完成启动过程 。

优化点五：关闭分层编译

（一）编译原理

从 JDK8 版本开始，Java 默认打开了多层编译，也就是分层编译机制。这一机制是 JVM 实现 “启动速度” 与 “运行效率” 平衡的核心机制 。在分层编译中，涉及到两个重要的编译器：Tier3 也就是 C1 编译器，以及 Tier4 即 C2 编译器。

当 Java 程序开始运行时，代码首先会被解释执行。在这个过程中，JVM 会监控字节码的执行频率，当发现某段代码（热点代码）被频繁调用时，就会触发编译操作。如果方法解释编译达到 2000 次以后，就会进行 C1 编译。C1 编译器编译速度快，它主要做一些基础的优化，如方法内联、常量传播、基本块调度等，生成的代码体积小、编译延迟低，适合启动阶段或对响应敏感的场景，能快速提升代码的执行速度。

而当 C1 编译后的代码执行次数达到 15000 次时，就会触发 C2 编译。C2 编译器编译速度较慢，但它会进行大量深度优化，如激进预测、循环优化、锁消除、逃逸分析、循环展开、向量化等，能最大化程序的峰值性能，生成的代码效率极高，非常适合长时间运行的服务端应用 。

（二）优化操作

如果我们希望提高 Spring Boot 应用的启动速度，可以通过命令使用 C1 编译器，同时配合关闭字节码验证的命令。在启动应用时，可以添加如下 JVM 参数：

-XX:TieredStopAtLevel=1 -XX:-VerifyBytecode

其中，\-XX:TieredStopAtLevel=1表示只使用 C1 编译器，停止在 Tier1 层，不进行 C2 编译；\-XX:\-VerifyBytecode表示关闭字节码验证。字节码验证是 Java 类加载过程中的一个重要环节，它会检查字节码是否符合 Java 虚拟机规范，是否存在安全隐患等。关闭字节码验证可以节省类加载时间，从而加快应用启动速度。

不过，需要特别强调的是，这种优化方式虽然能显著提高启动速度，但存在一定风险。关闭字节码验证意味着跳过了对字节码的安全性和合规性检查，如果代码中存在错误或安全漏洞，可能在运行时才被发现，导致应用出现异常甚至崩溃。因此，这种优化方式尽量不要在线上环境使用，一般只在开发和测试环境中，对启动速度有迫切需求且能确保代码质量的情况下采用 。