我是真没想到，这个面试题居然从11年前就开始讨论了，而官方今年才表态。

原创歪歪 why技术

大家好，我是歪歪。

这期给大家盘一个面试题啊，就是下面的第二题。

这个面试题的图片都被弄的有一点“包浆”了。

所以为了你的观感，我还是把第二道题目手打一遍。

啧啧啧，这行为，暖男作者实锤了：

spring 在启动期间会做类扫描，以单例模式放入 ioc。但是 spring 只是一个个类进行处理，如果为了加速，我们取消 spring 自带的类扫描功能，用写代码的多线程方式并行进行处理，这种方案可行吗？为什么？

老实说，我第一次看到这个面试题的时候，人是懵的。

我知道 Spring 在启动期间会把 bean 放到 ioc 容器中，但是到底是单线程还是多线程放，我还真不清楚。

所以我做的第一件事情是去验证题目中这句话：但是 spring 只是一个个类进行处理。

怎么去验证呢？

肯定是找源码啊，源码之下无秘密啊。

怎么去找呢？

这个就需要你个人的经验积累了，抽丝剥茧的去翻 Spring 源码，这个就不是本文重点了，所以我就不细说了。

但是我可以教你一个我一般用的比较多的奇技淫巧。

首先你肯定要搞个 Bean 在项目里面，比如我这里的 Person：

然后把项目日志级别调整为 debug：

logging.level.root=debug

接着启动项目，在项目里面找 Person 的关键字。

原理就是这是一个 Bean，Spring 在操作它的时候一定会打印相关日志，从日志反向去查找代码，要快的多。

所以通过 Debug 日志，我们能定位到这样一行关键日志：

Identified candidate component class: xxxx.Person.class]

然后全局搜索关键字，就能找到这个地方：

这个地方，就是打第一个断点的地方。

然后启动项目，从调用堆栈往前找，能找到这个地方：

这个类就是我要找的类：

org.springframework.context.annotation.ClassPathBeanDefinitionScanner#doScan

从源码上看，里面确实没有并发相关的操作，看起来确实是在 for 循环里面单线程一个个处理的 Bean 的。

那么从理论上讲，如果是两个没有任何关联关系的 Bean，比如我下面 Person 和 Student 这两个 Bean，它们在交给 Spring 托管，往 ioc 容器里面放的时候，完全可以用两个不同的线程处理嘛：

所以问题就来了：

如果为了加速，我们取消 spring 自带的类扫描功能，用写代码的多线程方式并行进行处理，这样可以吗？

可以吗？

我也不知道啊。

但是我知道去哪里找答案。

但是在找答案之前，我先大胆的猜一个答案：不可以。

为什么？

因为我看的是 Spring 5.x 版本的源码，在这个版本里面还是单线程处理 Bean。

对于 Spring 这种使用规模如此之大的开源框架来说，如果能支持多线程加载的话，肯定老早就支持了。

所以我先盲猜一个：不可以。

找答案

这个问题的答案肯定就藏在 Spring 的 issues 里面。

不要问我为什么知道。这是来自老程序员的直觉。

所以我直接就是来到了这里：

1.2k 个 issue，怎么找到我想要找的呢？

肯定是用关键词搜索一波。基于现在掌握的信息，你说关键词是什么？

肯定是我们前面找到的这个方法、这个类啊，这也是你唯一掌握到的信息：

org.springframework.context.annotation.ClassPathBeanDefinitionScanner#doScan

话不多说，先拿着类名搜一搜，看看啥情况。

从搜索结果上看，真的是一搜就中：

我带你看看这个 issue 的具体内容：

https://github.com/spring-projects/spring-framework/issues/28221

有个叫做 kyangcmXF 的同学...

呃，我第一眼看到他的名字的时候，看到有 F，K 还有 C，第一瞬间想起的是“疯狂星期四”。

那我就叫他“星期四”同学吧。

“星期四”同学说：我的项目有数以万计的 Bean 要被 Spring 初始化。所以每次项目启动的时候需要好几分钟才能完成工作。

然后他发现 doScan 的代码是单线程，一个一个的去处理 Bean 的。

所以他提出了一个问题：我是不是可以用 ConcurrentHashMap 来代替 Set 数据结果，然后并发加载。

他的问题和我们文章开头提出的面试题可以说是一模一样。而他甚至还给出了实现的代码：

然后这个 issue 下只有一个回复，是这样的：

首先，我们先看看这条回复的人是谁：

他就是 Spring 的 Contributors，他的回答可以说就是官方回答了。

他给“星期四”同学说：thanks 老铁，but not possible。

but post-processing bean definitions asynchronously is not possible at the moment.
目前不可能异步的对 bean 进行后置处理。

到这里，我们至少知道了，想用异步加载的方式确实是在实现上有困难，不仅仅是简单的单线程改多线程。

然后，这个老哥给“星期四”同学指了条路，说如果你想要进一步了解的话，可以看看编号为 13410 的 issue。

虽然我们现在已经有一个答案了，但是既然大佬指路了，那我肯定高低得带你去瞅上一眼。

还得从11年前说起

根据大佬指路的方向，我点开这个 issue 的时候都震惊了：

https://github.com/spring-projects/spring-framework/issues/13410

题目翻译过来是“在启动期间并行的处理 Bean 的初始化”，紧扣我们的面试题。

让我震惊的主要是这个 issue 的创建时间：2011 年 10 月 12 号。

好家伙，原来 11 年前大家就提出了这个问题并进行了讨论。

但是根据我多年在 github 上冲浪的经验，遇到这种“年久失修”的 issue 不能从头到尾的看，得反着来，得先看最后一个回复是什么时候。

所以我直接就是一个拉到最后，没想到最后一个回复还挺新鲜，是三个月前：

回答的这个哥们，也是 Spring 的官方人员，所以可以理解针对这个问题的官方回答：

这个哥们说了很长一段，我简单的翻译一下：

他说这个问题在最新的 6.0 版本中也不会被解决，因为它目前的优先级并不是特别高。

在处理真正的启动案例时，我们经常发现，时间都花在少数几个相互依赖的特定 bean 上。在那里引入并行化，在很多情况下并不能节省多少，因为这并不能加快关键路径。这通常与 ORM 设置和数据库迁移有关。

你也可以使用“应用程序启动跟踪功能”（application startup tracking）为自己的应用程序收集更多这方面的信息：可以看到启动时间花在哪里以及是如何花的，以及并行化是否会改善这种情况。

对于 Spring Framework 6.0，我们正专注于本地用例的 Ahead Of Time 功能，以及启动时间的改进。

到这里，就再次证明了官方对于并行化处理 bean 的态度：

但是这个哥们的回答中倒没有说“这个功能做不了”，他说的是“经过调研，这个功能实现后的收益并不大”。

而且他还透露了一个关键的信息，针对 Spring 启动速度，在 6.0 里面的方向是 AOT。

其这也不算透露，早在 2020 年，甚至更早，我记得 Spring 就说过以后的努力方向是 AOT，提前编译（Ahead-of-Time Compilation）。

如果你对于 AOT 很陌生的话，可以去了解一下，不是本文重点，提一下就行。

接下来，关于这个 11 年前的帖子，里面的内容还是比较多，我只能带你简单浏览一下帖子，如果你想要了解细节的话，还得自己去看看。

首先，提出这个问题的人其实已经提出了自己的解决之道：

核心想法还是在 Bean 初始化的时候引入线程池，然后并发初始化 Bean。只是需要特别考虑的是存在循环依赖的 Bean。

然后官方立马就站出来对线了：

小老弟，虽然从代码上看，在 Spring 容器中引入并发的 Bean 初始化看起来是直截了当的方法，但在实现起来并非看起来这么简单。重要的是我们需要看到更多的反馈和需求，当大家都在说“Spring 容器的初始化从根本上说太慢了”，我们才会认真考虑这种改变。

接着有个老哥跳出来说：我这边有个应用启动花了 2 小时 30 分...

官方针对这个时长也表示很震惊：

但是他们的核心观点还是：在 Spring 容器中并行化 Bean 初始化的好处对于少数使用 Spring 的应用程序来说是非常重要的，而坏处是不可避免的 Bug、增加的复杂性和意想不到的副作用，这些可能会影响所有使用 Spring 的应用程序，恐怕这不是一个有吸引力的前景。

官方还是把这个问题定义为"不会修复"，因为如果没有强有力的理由，官方确实不太可能在核心框架中引入这么大的变化。

这个观点也和他的第一句话很匹配：more pragmatic approach.

more 大家都认识。

approach，也应该是一个比较熟悉的单词：

那么 pragmatic 是什么意思呢？

这个单词不认识很正常，属于生僻词，但是你知道的，我写技术文的时候顺便教单词。

pragmatic，翻译过来是“务实的”的意思：

所以“more pragmatic approach”，是啥意思，来跟我大声的读一遍：更务实的方法。

官方的意思是，更务实的方法，就是先找到启动慢的根本原因，而不是把问题甩锅给 Spring，关键是这是核心逻辑，没有强有力的理由，能不动，就别动。

然后期间就是使用者和官方之间的相互扯皮，一直扯到 5 年后，也就是 2016 年 6 月 30 日：

官方重要决定：好吧，把这个问题的优先级提升一下，提升为"Major"任务，保留在 5.0 的积压项目中。

但是...

好像官方这波放了鸽子。

直到 2018 年，网友又忍不住了，这个啥进度了呀？

没有回应。

又到了 2019 年，啥进度了啊，我很期待啊：

还是没有回应。

然后，时间来到了 2020 年。

三年之后又三年，现在都 9 年了，大佬，啥进度了啊？

斗转星移，白驹过隙，白云苍狗，换了人间。时间很快，来到了 2021 年。

让我们共同恭喜这个 issue 已经悬而未决 10 周年了：

最后，就是今年了，7 月 15 日，网友提问：有什么好消息了吗？

官方答：别问了，我鸽了，咋滴吧？

怎么才能快？

在寻找答案的过程中，我找到了这样的一个项目：

https://github.com/dsyer/spring-boot-allocations

这个项目是对于不同版本的 Spring Boot 做了启动时间上的基准测试。

测试的结论最终都被官方采纳了，所以还是很有权威性的。

整个测试方法和测试过程以及火焰图什么都在链接里面贴了，我就不赘述了。

只是把最后的结论搬出来，给大家看看：

我按照自己的理解翻译一下。

首先，如果你要采用下面的方法，你就要放弃一些功能，所以不是所有的建议都能适用于所有的应用程序。

从 Spring Boot web starters 中排除下面这些 Classpath：Hibernate Validator；Jackson（但Spring Boot actuators 依赖于它）。如果你需要JSON渲染，请使用 Gson；Logback：使用slf4j-jdk14代替
使用 spring-context-indexer，它不会有很大的帮助，但是有一点点，算一点点。
如果可以，别使用 actuators。
使用 Spring Boot 2.1 和Spring 5.1 版本。当 2.2 和 5.2 可用时，升级到 2.2 和 5.2 版本
用 spring.config.location（命令行参数或 System 属性等）固定 Spring Boot 配置文件的位置。
如果你不需要 JMX，就用 spring.jmx.enabled=false 来关闭它（这是 Spring Boot 2.2 的默认值）。
把 Bean 设置为 lazy，也就是懒加载。在 Spring Boot 2.2 中有一个配置项 spring.main.lazy-initialization=true 可以用。
解压 fat jar 并以明确的 classpath 运行。
用 -noverify 运行JVM。也可以考虑 -XX:TieredStopAtLevel=1 。目的是关闭分层编译。

至于每个点背后的原因，答案就藏在前面说到的 issue 里面，感兴趣，自己去翻，我就是指个路，就不细说了，有兴趣自己去翻一翻。

好了，本文的技术部分就到这里啦。

下面这个环节叫做[荒腔走板]，技术文章后面我偶尔会记录、分享点生活相关的事情，和技术毫无关系。我知道看起来很突兀，但是我喜欢，因为这是一个普通博主的生活气息。