1. 先说说这个性能项目是怎么立项的1.1 启动时间为什么值得优化在微服务数量多起来的场景里每次发布、扩容、重启本质上都是在跟时间赛跑。以前我也觉得“启动 5 秒没什么”直到有一次线上需要紧急扩容一批服务冷启动直接把容器调度的节奏拖慢业务侧反馈“发布一次要等半天”。那一刻才真正意识到启动时间不是小事它直接影响扩缩容效率、发布节奏和故障恢复速度。尤其是那种对延迟敏感的业务多等 1 秒都意味着成本。Spring Boot 的优势是“开箱即用”代价就是启动时要做大量 Bean 创建、自动配置解析、类加载和资源初始化。一个中等规模的应用从主方法执行到日志打出Started ... in X seconds时间基本花在类加载与字节码处理、Spring 容器初始化、自动配置装配、数据源连接池预热、日志系统初始化、内嵌容器启动这几个环节。它们互相嵌套光凭直觉很难判断到底哪里慢。这篇内容适合谁适合正在维护 Spring Boot 服务、对发布效率有要求的后端开发者尤其是服务数量多、每次重启都要等很久、但不敢随便乱改配置的团队。我写的不只是理论而是把整个优化过程从头到尾拆开哪些配置改了有效、哪些是坑、哪些纯属自欺欺人都一次说清楚。1.2 5 秒到 1 秒的目标到底差在哪把目标定成 1 秒以内不是拍脑袋。微服务场景下启动 1 秒可以接受3 秒勉强5 秒以上就需要专门优化了。而“从 5s 到 1s”本质上要完成三个层面的变化减少加载和装配的工作量能不放进去的 Bean、能不算的自动配置尽量不加载。减少启动期的等待连接池初始化、外部服务连接、缓存预热能延后的延后。减少 JVM 和框架层的额外开销类加载、字节码增强、GC、编译器分层等。这样拆完之后就会发现启动时间并不是靠某一个“大杀器”配置减下来的而是靠一系列小项累积。每个配置项砍 200 毫秒、500 毫秒加起来才有这个效果。我后面的实操就是按这个思路一步步来的。1.3 优化前的基线数据动任何代码之前先把基线量住。我当时在项目里做的第一件事不是盲改配置而是先记录原状。环境某中等规模微服务Spring Boot 2.7.xJDK 118C16G 容器服务约 120 个业务 Bean依赖了 Redis、MySQL、消息队列等组件。启动耗时日志显示Started MonitorServiceApplication in 4.976 seconds。我把这个时间记下来作为后面所有改动的对照基准。这里有个很重要的经验性能优化必须先有基线否则改了一堆东西效果全靠感觉最后根本没法回归。后面所有优化项我都是“改一项、测一项、记录一项”而不是一次性全改完再跑。2. 定位瓶颈5 秒究竟烧在了哪儿2.1 三种有效的启动耗时收集方式先说我试下来最好用的三种方式。第一种是看 Spring Boot 自带的启动事件记录。Spring 容器的启动过程分成多个阶段Boot 的StartupStepMetrics可以记录每个阶段耗时。只要引入spring-boot-starter-actuator然后配置management.endpoints.web.exposure.includestartup启动后访问/actuator/startup就能看到类似这样的数据{ timeline: { startTime: 2025-01-01T08:00:00.000Z, steps: [ { name: spring.beans.instantiate, duration: 0.658 }, { name: spring.context.refresh, duration: 1.234 }, { name: spring.beans.autowire, duration: 0.412 } ] } }这个信息量很大能清楚看到到底是 Bean 创建阶段耗时最多还是环境准备阶段耗时最多。第二种是 JVM 自带的 JFR。JDK 11 以上可以直接用java -XX:StartFlightRecordingfilenamestart.jfr,settingsprofile -jar app.jar启动采集到的 jfr 文件打开后能看到类加载、方法编译、GC 等所有 JVM 事件。想精确定位某个类加载耗时、启动阶段发生多少次 GC用 JFR 最直接。第三种是-verbose:class它会把每个类的加载情况打印到标准输出。启动结束后统计日志java -verbose:class -jar app.jar class.log 21 grep class load class.log | wc -l这个方法虽然粗糙但能直观感受类加载规模。我优化的那个项目启动过程中加载了 4000 多个类其中很多来自用不上但被自动配置拉进来的依赖。2.2 解读启动日志和分析结果拿到原始数据后怎么定位瓶颈我的经验是分两条路。一条是看 Spring 容器阶段。用/actuator/startup或启动日志把时间按阶段归类。常见耗时大户包括spring.beans.instantiate、spring.context.refresh、spring.event。如果 Bean 实例化耗时占比高说明问题出在 Bean 太多、部分 Bean 初始化逻辑太重、或者自动配置带进来了不用的基础设施组件。另一条是看 JVM 层。从 JFR 里拉出启动阶段的类加载总数、GC 耗时、方法编译耗时。如果 GC 耗时高说明启动过程创建了大量临时对象如果编译耗时高说明 JIT 编译器在启动时做了太多编译如果类加载数量巨大需要找来源。我那次分析的结论大致是Bean/配置装配占掉 2.3 秒左右数据源和连接池初始化接近 1 秒日志和容器启动等其他环节占掉剩下的 1.6 秒JVM 本身的开销反而没有想象中那么大。这就明确了主线任务是先把 Bean 装配和连接池初始化的时间打下来。2.3 耗时分布最典型的几个重灾区结合几个项目里看过的数据我总结启动耗时的重灾区基本是这几类大量 Bean 实例化特别是Service、Repository、Component标注的类多而且很多在构造器里做校验、加载配置、创建线程池。自动配置误伤导入一个中间件 starter结果把一批无关的XxxAutoConfiguration全部激活。比如引入了某个客户端但当前服务根本不用它它还是会被自动配置检测出来。数据源连接池预热HikariCP 默认在启动时建立minimumIdle个连接如果数据库网络有延迟启动会被明显拖住。日志初始化Logback 启动时扫描配置文件、创建各种 appender单次开销不大但会带来连锁的类加载。内嵌容器初始化Tomcat 启动线程池、连接器绑定也需要几百毫秒。看到这些重灾区之后后面的优化项基本就是对着它们逐一开刀。3. 应用层优化配置和代码层面逐个击破3.1 第一步把用不上的自动配置裁剪掉这是效果最明显、也最容易犯错的环节。SpringBootApplication默认会扫描整个包结构并按spring.factories激活一大堆自动配置。只要类路径里有相关 jar它就会按条件装配哪怕当前服务根本不需要。我之前那个项目依赖里有 Redis 客户端、消息队列客户端但服务本身只做入仓调度根本用不到 Redis。结果启动日志上清清楚楚显示RedisAutoConfiguration、AopAutoConfiguration、DataSourceAutoConfiguration等一堆配置被激活了。裁剪方式很简单SpringBootApplication(exclude { RedisAutoConfiguration.class, MongoAutoConfiguration.class, ElasticsearchRestClientAutoConfiguration.class })或者写在配置文件里spring: autoconfigure: exclude: - org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration - org.springframework.boot.autoconfigure.data.mongo.MongoDataAutoConfiguration这一项在我那个项目里省了约 0.6 秒。因为它不仅省掉了相关 Bean 的创建还省掉了大量 jar 包里的类加载和条件评估逻辑。但这里必须提醒排除自动配置不能乱来。有的配置看起来没用实际是另一套机制的支撑。比如排除DataSourceAutoConfiguration后如果代码里没有显式的DataSource定义服务直接起不来。排除每一项之前先启动一次看有没有报错再做功能回归后面我在避坑清单里专门讲这个。3.2 收窄包扫描范围减少无谓候选SpringBootApplication默认扫描的是它所在包及其子包。服务大了以后容易把很多不属于这个模块的类也扫进来。虽然 Spring 在筛查候选时会用条件匹配但候选多了ASM 元数据读取和条件评估都要耗时。收窄扫描用scanBasePackages显式指定SpringBootApplication(scanBasePackages com.example.module)如果能精确到某个子包会比写“整个项目包”更快。另外ComponentScan里搭配excludeFilters也能进一步排除无关候选但实际项目里我觉得把包结构理干净更根本。这里有个容易被忽略的点包扫描省掉的不只是扫描时间还有候选 Bean 的元数据解析时间。比如原来扫了 2000 个类最后可能只注册 100 个 Bean但 2000 个类的注解元数据都会被框架读取一遍。扫描范围收窄之后这部分的 IO 和 CPU 都省下来了。实测这步让启动时间又少了 0.4 秒左右。3.3 Bean 初始化、懒加载与延迟启动后置任务Bean 实例化是启动耗时的核心。我采用的优化策略分三个层次按影响面从小到大排列。第一层只给特定重 Bean 加Lazy。比如某个Component构造器里初始化了一个线程池而这个线程池在启动阶段根本不会被用到就标注Lazy。把这类 Bean 列清楚逐个加注解影响最小风险可控。第二层开启全局懒加载spring: main: lazy-initialization: true这能一次性抹掉很多 Bean 创建的时间但副作用也大第一次真正调用某个 Bean 时它才初始化表现为“启动快了但第一个请求很慢”。处理办法后面在避坑清单里细说。我个人不建议上来就全局懒加载应该先统计哪些 Bean 真的需要在启动时创建。第三层把启动期的“任务”拆开。凡是能用ApplicationReadyEvent延迟执行的就不要用PostConstruct或InitializingBean。比如缓存预热、远程配置拉取、向外部系统上报自身状态写成Component public class WarmupRunner { EventListener(ApplicationReadyEvent.class) public void warmup() { // 启动完成后再预热不让它拖慢就绪时间 } }这个动作在架构上更合理也顺带把启动时间和“业务就绪”解耦。有些团队把所有预热逻辑塞进PostConstruct导致健康检查半天不通过这就是典型的分不清“进程起来”和“业务就绪”的区别。3.4 日志、数据源连接池、内嵌容器的启动参数这三个模块看着是基础设施其实能挖出的省时空间不小。日志这块Logback 初始化本身不长但如果你在配置里写了很多appender尤其是网络 appender、异步 appender启动时会解析 XML、创建 appender 对象。一个值得做的小优化是禁用 Bannerspring: main: banner-mode: off别小看那几行 ASCII 艺术字它也要走一次字符串渲染和输出虽然量级是几十毫秒但小项叠加起来就明显了。日志等级不用全局压制但可以把用不上的框架日志关掉logging: level: root: info org.springframework: warn com.zaxxer.hikari: warn数据源连接池是启动等待的主要来源之一。HikariCP 默认会在启动阶段创建minimumIdle个连接如果网络不稳或数据库连接耗时高启动会被明显拖住。可以把最小空闲连接设为 0并调低初始化失败超时spring: datasource: hikari: minimum-idle: 0 initialization-fail-timeout: 1 connection-timeout: 5000这个配置的意思是启动时不要求连接池完全初始化连接按需创建即使初始化失败也只给 1 秒容错时间。缺点是第一个数据库请求会多等一个连接的创建时间但这个时间通常远小于启动整体省下来的时间。内嵌容器方面Tomcat 启动流程里线程池创建、连接器绑定都会占时间但能调的参数有限。比较有效的思路是开发/测试环境把线程数设置为合理值避免启动时创建过大的线程池生产环境可以结合预热器让请求在容器完全就绪后再进入。还有一个常用的配置spring: mvc: servlet: load-on-startup: -1普通服务基本不需要在启动时就加载 Servlet保持默认即可。4. JVM 层优化编译器、GC 与类数据共享4.1 调整 JVM 参数对启动时间的影响应用层改完还剩一大块是 JVM 自身。同样的 jar 包不同 JVM 参数启动时间能差出 0.5 到 1 秒。最常用的一组启动优化参数java -XX:TieredStopAtLevel1 -XX:UseSerialGC -Xmx512m -Xms256m -jar app.jar-XX:TieredStopAtLevel1的意思是只用 C1 编译器不做 C2 深度编译。启动时 JIT 会少做很多编译工作自然更快。代价是运行期热点代码的峰值性能下降对长时间高负载服务不太合适更适合短时任务、开发环境、或者对启动时间极其看重的场景。我用它之前先做了压测对比确认接口性能没有明显恶化才保留。GC 方面-XX:UseSerialGC用单线程串行回收器在启动阶段、年轻代对象多但堆小的场景下比 G1 更省资源。G1 启动时要初始化很多复杂结构串行 GC 基本就是一块区域里扫启动期 GC 停顿反而更短。但生产环境堆很大的服务不建议长期用 SerialGC它的性能上限最低。-Xmx和-Xms也很重要。启动时如果堆从很小慢慢扩会反复触发扩容和 GC。把初始堆设成接近最大堆能减少启动期的堆管理开销。但不要为了图快把-Xms设得超过实际需要毕竟内存是稀缺资源。4.2 类数据共享 AppCDS 的实测效果AppCDS 是 Java 类数据共享机制本质是把类加载后的元数据打包成共享归档文件下次启动时直接从归档加载省掉重复读取 jar 和解析字节码的过程。对 Spring Boot 这种类特别多的应用收益明显。操作步骤很简单。先用“训练启动”生成归档java -XX:ArchiveClassesAtExitapp.jsa -jar app.jar然后正常启动时复用java -XX:SharedArchiveFileapp.jsa -jar app.jar使用前有几个硬性条件JDK 小版本要一致jar 包类路径要一致生成归档和应用启动的机器环境尽量一致。在容器场景里最有保障的做法是在镜像构建阶段生成归档并保证运行时和构建时用的是同一个基础镜像。我那个项目用上 AppCDS 后启动时间又压掉了约 0.3 到 0.5 秒。这个档位对冲击 1 秒以内的目标很关键。如果使用过程中报“unable to map shared archive”或“shared archive file not used”多半是 JDK 版本或类路径变了重新生成即可。Spring Boot 3 里如果开启了 AOT它与 CDS 的配合会更紧密但传统 jar 包直接用 JVM 的 CDS 就足够。4.3 哪些 JVM 手段不建议在业务项目里乱用这一节是想给大家泼点冷水。网上有很多“启动秒开”的参数组合实际要分场景。-XX:TieredStopAtLevel1对长时间运行的 web 服务不友好C2 编译器缺席带来的峰值性能下降可能让接口 P99 变差。生产系统要上必须先压测。-Xverify:none这类参数在低版本 JDK 里确实能省验证时间但高版本 JDK 已经移除了它的实际效果而且关闭字节码验证有安全风险生产环境千万别加。还有一类“假优化”把spring.main.log-startup-infofalse配上日志里不打印Started ... in X seconds看起来启动“变快”了但实际上什么都没省。写代码的时候要对自己诚实性能优化的目标是降低真实耗时不是把计时器关掉。5. 优化效果数据与回归验证5.1 各阶段耗时对比看看省在哪里以下是我项目里的真实记录单位是毫秒。不同项目绝对数值不同但分配比例有参考价值阶段优化前第一轮后第二轮后Spring 容器装配2360620360数据源/连接池初始化940260120日志与 Banner1604040内嵌容器启动430380380JVM 启动开销760320180其他326200110合计497618201190第一轮优化后从 4.976 秒降到了 1.82 秒。第二轮我做了三件事给确定不用启动加载的 Bean 加局部懒加载、把预热任务全部改成ApplicationReadyEvent触发、用 AppCDS 归档进一步压 JVM 开销跑完是 1.19 秒。最后又清理掉一批冗余 Bean 和定时任务的启动期初始化稳定在 1.0 秒附近日志显示Started ... in 1.023 seconds。这里我想给个建议做优化记录时不要把“总耗时”当唯一指标。我会额外记录“类加载数量”“注册 Bean 数量”“启动期 GC 时间”这几个中间指标方便后续排查哪里有反弹。5.2 功能回归怎么做优化启动时间最怕的是改完启动飞快接口全挂。我当时的回归方案分成四步。第一步健康检查。启动完后立刻访问/actuator/health确认状态 UP并且相关组件数据源、Redis 等的 HealthIndicator 都正常。这一步能暴露大部分自动配置排除问题。第二步核心接口回归。挑出日常请求量最大的几个接口启动后立刻调用一遍确认返回状态码和关键字段正常。尤其要关注用了懒加载的 Bean 是否在首调时报错。第三步慢接口检查。因为连接池懒初始化了第一次数据库请求可能会慢我要记录建立连接的时间确认它在可接受范围内而不是极端地拖到接口超时。第四步观察一段时间。发布到预发环境后跑一轮定时任务和消息消费确认那些“启动后才触发的链路”都正常。启动优化最容易漏掉的就是“启动时没跑所以看起来正常”的逻辑。5.3 如何让优化效果不随时间退化优化完不是一劳永逸。团队其他成员后续加依赖、加 Bean 时可能又把类加载数拉上去。我采取的做法是把检查点固化到 CI用脚本在每次构建后解析启动日志中的Started ... in X seconds超过阈值就报警。定期统计-verbose:class的类加载数量变化超过 20% 时人工 review。自动配置裁剪清单写成文档新增依赖时对照检查避免有人把不必要的客户端加到模块里。这些措施不能保证性能永远最优但能保证它不会悄无声息地恶化。6. 常见问题与避坑清单这条路上踩过的坑6.1 我最想吐槽的几个坑先列一个速查表都是我亲自踩过或者帮别人排过的现象原因解决办法全局懒加载后首请求超时大量 Bean 首次初始化积压只对确定被访问的链路局部懒加载或预热关键 Bean排除数据源自动配置后启动报错没有显式 DataSource Bean保留自动配置或显式声明 DataSource排除自动配置后 JSON 接口异常排除 Jackson 相关配置重新检查排除清单恢复必要配置AppCDS 提示无法使用JDK 版本或类路径变化重新生成 app.jsa启动变快但接口变慢TieredStopAtLevel1 影响峰值性能压测对比生产谨慎使用容器启动很慢但本地很快DNS 解析、hosts 配置异常检查 /etc/hosts避免反向 DNS 耗时6.2 懒加载引发的实例化异常我后来是怎么处理的全局懒加载那段时间遇到过最典型的问题一个用了Scheduled的任务 Bean启动后没有立即实例化结果定时任务调度器初始化被推迟到第一次执行时看起来像是丢了一轮任务。排查时用/actuator/beans看到一堆 Bean 的lazyInittrue才知道是全局懒加载造成的。后来我把策略改成了“白名单式局部懒加载”默认全部正常初始化只对确定不需要启动即用的 Bean 加Lazy再对启动链路里必须存在的 Bean 显式标Lazy(false)。这样既保证了启动快又不影响调度、监听和外部连接类组件。如果你的服务里也有Scheduled、ApplicationListener这类依赖容器启动时执行语义的 Bean建议和我一样避免全局懒加载。6.3 排除自动配置后的连锁反应排除自动配置是最容易见效也最容易翻车的地方。我见过一个项目开发同学为了减启动时间把一个XxxAutoConfiguration排除掉服务确实启动快了 0.3 秒但因为这个配置偷偷注册了某个Formatter导致接口返回值格式变了直到线上用户反馈才发现。所以“排除自动配置”一定要有闭环验证。推荐的做法是先在本地启动用/actuator/conditions端点查看自动配置的匹配条件和生效情况确认要排除以后再启动启动后立刻检查健康端点和核心接口。不要同时排除多个配置项那样一旦出问题你根本不知道是哪一个导致的。6.4 CDS 和容器环境的兼容问题容器里用 AppCDS 有两个特别容易踩的坑。第一镜像构建阶段生成的app.jsa与运行时的 JDK 或类路径不一致。如果你用多阶段构建构建阶段是 JDK 17.0.5运行时却换成 17.0.9归档文件可能直接失效。解决方式是让构建与运行的 JDK 版本严格一致最好用同一个基础镜像。第二CDS 需要类路径可重现。如果你用 shade 打了一个包含所有依赖的 fat jar然后在启动命令里动态拼了 classpathCDS 就很容易失效。Spring Boot 的可执行 jar 本身类路径是固定的配合 CDS 比较顺畅。不要在手写 classpath 的场景强行上 CDS排查起来非常痛苦。7. 最后说几句实操体会这一轮优化做完我最大的感受是启动时间优化不是“一个大招见效”而是几十个小改进累积出来的。每项改动单独看都只有几百毫秒但全部叠加起来从 5 秒压进 1 秒是完全能做到的。我实际留下来的“标准动作”其实就三条先量基线再动手每一项改动单独验证把检查点固化到 CI。这三条对任何性能优化课题都适用比记住某个具体参数重要得多。还有一个细节想分享一下优化完成后我把这套改动整理成了一份“启动优化检查清单”每次新服务上线前都会过一遍包含自动配置排除是否合理、有没有不该初始化的连接池、有没有不必要的预热、JVM 参数是否经过压测这四类问题。这套清单后来帮团队省了不少排查时间。如果你的服务启动也很慢建议先从日志和/actuator/startup开始看看时间到底花在哪再决定要不要上全局懒加载或 CDS。盲目抄别人的参数组合大概率会把某个连接池或定时任务搞出隐性故障。技术优化最忌只看表面数据希望这篇实战记录能帮你少走点弯路。