Spring 启动时长优化是否有必要

[linyimin520812]

最近在 reddit 上推广自己的关于 Spring 启动优化小项目，之前也在 v 站推广过：

• 分享一种 Spring 应用启动过程采样的方法
• Spring 启动分析优化——自荐个项目

评论区有个评论者 ta 的意见是没有意义，理由如下：

一开始看到这个评论还挺难过的，毕竟辛苦做的东西，被别人说的一文不值。后面去了解了一下这个开发者说的 GraalVM ，发现确实很强大，编译出的 native 启动速度确实非常的快。

所以我也开始认真的思考这个项目是否真的有意义，这个项目的背景是公司为了降低线上故障时回滚止血时间，要求应用启动时长必须要小于指定的时间，结合一些可以显著提高 Java 启动速度方法无观测不优化的观点实现的，最大的一个优化应用是：将启动时间由原来的将近 6 分钟优化至 3 分钟。

如果没有公司的强推，那还有没有必要这样做 spring 应用启动的优化，就像评论说的直接使用 GraalVM 。个人觉得还是有必要的：

• 目前公司的应用不是基于 GraalVM 的，如果要享受 GraalVM 带来的启动极速，还是需要进行大量的应用改造
• GraalVM 对反射、动态代理有很多的限制，升级应用很容易踩坑，还需要大量的回归测试
• 日常的项目启动慢本身其实不在 spring 本身，而是项目中依赖的各种中间件的初始化、富客户端的初始化等导致的，升级完 GraalVM 后这些耗时应该还是存在的

以上就是我能想到的观点，感觉这个评论者是 GraalVM 的忠实粉丝，而且认为这是在发布垃圾消息，所以选择在 v 站想和大家再讨论一下，spring 启动时长的优化是否有必要

[shimada666]

当然有必要了，类似前端的 vite ，把 webpack 的冷启速度从一分钟干到秒级，对开发效率是多大的提升

[linyimin520812]

@kaedeair 日常开发部署时等待的时间也很难受😂

[linyimin520812]

@superchijinpeng 使用 quarkus graalvm 的限制多吗？对开发人员的要求是不是要更高一点呀？

[shyangs]

大項目會上 HA 叢集(clusters)，可以依次或隨用停用伺服器進行版更.

小項目，停機一個上午/下午/晚上進行更新也沒事. (很多網遊/手遊、ERP 都是這個模式，也沒見玩家、員工跑光了)

綜上，不論大項目、小項目版更重啟時間都沒有追分奪秒的急迫性.

[perfectlife]

我只想说 大部分公司 java 开发根本不看这些

[abcbuzhiming]

GraalVM 这东西还不到能大规模使用的地步，很多使用了反射的库和框架根本没法在这个 jvm 下使用。

而且还有一个问题，这东西启动是快啊，编译的贼慢怎么没人提，编译时间快赶上 C++了

[superchijinpeng]

@linyimin520812 #23 要求不高，社区活跃，文档全，加上 kotlin 效率高的不是一点半点，要说问题就是编译时间长，不过有 ci

[linyimin520812]

@miaotaizi 线上出现故障回滚的时候，启动速度越快，回滚越快，损失就越小，而且故障级别是按照止血时间定级的，启动越快，故障级别可能就越低

[linyimin520812]

@shyangs 线上出现故障回滚的时候，启动速度越快，回滚越快，损失就越小，而且故障级别是按照止血时间定级的，启动越快，故障级别可能就越低。启动速度快，日常开发效率、体感也相对会好很多

[interim]

@abcbuzhiming 编译都在服务器上，也只有需要上生产才编译二进制，正常开发不需要编译二进制，其实没啥影响。

[6IbA2bj5ip3tK49j]

老外说了一大堆，其实重点只是最后一句：stop spamming

[XJohn]

就一个问题：
假设部署的节点都不可用了，需要迁移到其他节点，多久启动意味着多久服务不可用。

[yazinnnn]

@linyimin520812 如果写了对应依赖的 aot 扩展, 那么这些依赖初始化工作会在 build 期进行, 应用的启动时间和内存占用就会降低

[gam2046]

还是挺支持这种优化的，但是就我自己而言，还是老咸鱼，觉得没必要。

既然我都用 Spring 全家桶了，就是来享受它的便利了，也就没那么在乎资源占用和启动速度了。

要是我一开始就很在意的话，就直接用 Golang 了。

[linyimin520812]

@yazinnnn #33 这个有相关的介绍文档吗？没接触过这块

[xiaocaiji111]

1 分钟内都可以接受，目前除了遇到政府项目需要启动 10 分钟左右，各种链接什么的初始化。一般项目不到 20 秒就起来了。再优化没有意义。

[linyimin520812]

@xgfan 我感觉这不是 spamming ，因为并没有被版主移除😂

[DinnyXu]

OP 你的优化是帮助一些现有的框架进行提升，这是没问题的，也是能解决当下问题的，只不过 GraalVM 是未来的趋势，可能像你说的一样，不适用现有的老项目，但是未来的新项目可以围绕 GraalVM 去设计，那么启动速度这块自然就快了，所以你跟评论者站的不是一个角度看待问题。没有关系，你继续优化也没有什么问题的

[xiaooloong]

老外明显是口嗨+1 。
厂里之前用 springcloud 1.x 的时候启动速度感人。后来新开的项目换了 2.x 提升了不少。
但是随着业务发展引入的库越来越多，速度也开始慢起来了。
最终为了做 apm 引入了 java agent ，启动时间直接爆炸。

[me1onsoda]

我认为启动时长、吃内存是 spring 或者 Java 的最大的痛点