Spring Boot 启动耗时从 90 秒压到 25 秒,做了这几件事
【摘要】 服务膨胀到200多个Bean之后,启动时间涨到90秒,发布一次等得人焦虑。这周下决心治了一下,最后稳定在25秒左右,记录下做的事。第一步是量化。打开Actuator的startup端点,配合spring-startup-analyzer生成时间线,发现耗时大头有三块:几十个@PostConstruct里的远程配置拉取、JPA实体扫描,以及一个老同事写的启动期全量表结构校验,单这一项就18秒。...
服务膨胀到 200 多个 Bean 之后,启动时间涨到 90 秒,发布一次等得人焦虑。这周下决心治了一下,最后稳定在 25 秒左右,记录下做的事。
第一步是量化。打开 Actuator 的 startup 端点,配合 spring-startup-analyzer 生成时间线,发现耗时大头有三块:几十个 @PostConstruct 里的远程配置拉取、JPA 实体扫描,以及一个老同事写的启动期全量表结构校验,单这一项就 18 秒。
按端点给出的结论逐项处理:
spring:
main:
# 非核心 Bean 延迟初始化
lazy-initialization: true
autoconfigure:
exclude:
- org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
jpa:
open-in-view: false
懒加载开了之后要留例外:定时任务、消息监听器这些 Bean 必须饿汉式初始化,否则任务不跑,用 @Lazy(false) 或在配置里排除。那个表结构校验改成启动后异步执行,失败再告警。远程配置拉取从串行改并行,CompletableFuture 一把梭,6 段串行 12 秒变 2 秒多。
还有个细节:open-in-view 关掉之后,几个在 Filter 里读实体的接口报 LazyInitializationException,老老实实改成了 DTO 查询。这也是很多人不敢关 OSIV 的原因,建议趁早还债。
最后把 devtools 的 restart 从流水线里去掉(容器场景没意义),CI 的启动冒烟加上 -XX:TieredStopAtLevel=1,本地调试能再快 30%。启动慢不是玄学,端点数据摆在那,先测量再动手,比瞎猜有效得多。
【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论(0)