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

约定不等于承诺〃 2023-10-03 21:22 3阅读 0赞

![format_png][]

大家好，我是歪歪。

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

![format_png 1][]

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

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

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

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

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

![format_png 2][]

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

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

怎么去验证呢？

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

怎么去找呢？

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

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

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

![format_png 3][]

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

> logging.level.root=debug

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

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

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

> Identified candidate component class: xxxx.Person.class\]

![format_png 4][]

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

![format_png 5][]

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

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

![format_png 6][]

这个类就是我要找的类：

> org.springframework.context.annotation.ClassPathBeanDefinitionScanner\#doScan

![format_png 7][]

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

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

![format_png 8][]

所以问题就来了：

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

可以吗？

我也不知道啊。

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

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

为什么？

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

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

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

![format_png 9][]

### 找答案 ###

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

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

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

![format_png 10][]

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

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

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

> org.springframework.context.annotation.ClassPathBeanDefinitionScanner\#doScan

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

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

![format_png 11][]

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

> [github.com/spring-proj…][github.com_spring-proj]

![format_png 12][]

有个叫做 kyangcmXF 的同学...

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

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

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

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

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

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

![format_png 13][]

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

![format_png 14][]

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

![format_png 15][]

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

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

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

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

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

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

![format_png 16][]

### 还得从11年前说起 ###

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

> [github.com/spring-proj…][github.com_spring-proj 1]

![format_png 17][]

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

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

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

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

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

![format_png 18][]

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

![format_png 19][]

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

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

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

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

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

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

![format_png 20][]

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

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

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

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

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

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

![format_png 21][]

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

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

![format_png 22][]

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

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

![format_png 23][]

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

![format_png 24][]

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

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

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

more 大家都认识。

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

![format_png 25][]

那么 pragmatic 是什么意思呢？

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

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

![format_png 26][]

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

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

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

![format_png 27][]

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

但是...

好像官方这波放了鸽子。

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

![format_png 28][]

没有回应。

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

![format_png 29][]

还是没有回应。

然后，时间来到了 2020 年。

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

![format_png 30][]

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

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

![format_png 31][]

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

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

![format_png 32][]

![format_png 33][]

### 怎么才能快？ ###

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

> [github.com/dsyer/sprin…][github.com_dsyer_sprin]

![format_png 34][]

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

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

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

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

![format_png 35][]

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

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

*  从 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 里面，感兴趣，自己去翻，我就是指个路，就不细说了，有兴趣自己去翻一翻。

[format_png]: https://img-blog.csdnimg.cn/img_convert/ba35a962988ec09309ee2eaf6e6bba66.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/fbb806a1b1435004511141203dbb3480.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/0fe192b77bd6f833e827470245a7a9cc.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/0342354d155d5645956e5a0facab2b1f.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/dbfbc04fe5856b752827867af21918af.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/f6c9a5ee5bc4c412a2ed0cd175dd71e5.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/d3816373810e4dc57a83a590d68d04bf.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/0c9fe64df681b290a0a5b26c00b86139.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/520941bf01a518783c592234f948d50b.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/fd189033a7afcaed51e55663d4674121.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/71d96f38d117f095ec91f85190b027da.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/54f358c63105ffeb5ae57264af3fc7b9.webp?x-oss-process=image/format,png
[github.com_spring-proj]: https://link.juejin.cn/?target=https%3A%2F%2Fgithub.com%2Fspring-projects%2Fspring-framework%2Fissues%2F28221
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/c7ff39f12db652637efca7693e584735.webp?x-oss-process=image/format,png
[format_png 13]: https://img-blog.csdnimg.cn/img_convert/584d5e5d7db6946e3b78c78e0197c7b7.webp?x-oss-process=image/format,png
[format_png 14]: https://img-blog.csdnimg.cn/img_convert/253793b29741c5a2c6a6e35788daec6f.webp?x-oss-process=image/format,png
[format_png 15]: https://img-blog.csdnimg.cn/img_convert/e95e8b6e60f655d34df8ca05b84a5ee7.webp?x-oss-process=image/format,png
[format_png 16]: https://img-blog.csdnimg.cn/img_convert/397316cab87b0894a51ec9ddbf1d15fb.webp?x-oss-process=image/format,png
[github.com_spring-proj 1]: https://link.juejin.cn/?target=https%3A%2F%2Fgithub.com%2Fspring-projects%2Fspring-framework%2Fissues%2F13410
[format_png 17]: https://img-blog.csdnimg.cn/img_convert/47c31993cdbef3c4629eb5bf21545cda.webp?x-oss-process=image/format,png
[format_png 18]: https://img-blog.csdnimg.cn/img_convert/3f4942025e2a6e48c54ca2f885709e81.webp?x-oss-process=image/format,png
[format_png 19]: https://img-blog.csdnimg.cn/img_convert/d5a3d9e010403005bcdec7e4b42f9007.webp?x-oss-process=image/format,png
[format_png 20]: https://img-blog.csdnimg.cn/img_convert/059c55524f26b771ecff92383d581ee7.webp?x-oss-process=image/format,png
[format_png 21]: https://img-blog.csdnimg.cn/img_convert/81e78572cc53e7fa519bef4699a5ab75.webp?x-oss-process=image/format,png
[format_png 22]: https://img-blog.csdnimg.cn/img_convert/93e47e128fe4425b3fd182a3dac9a1f0.webp?x-oss-process=image/format,png
[format_png 23]: https://img-blog.csdnimg.cn/img_convert/48f304868bb20c42273d3f88458385a7.webp?x-oss-process=image/format,png
[format_png 24]: https://img-blog.csdnimg.cn/img_convert/7cc65e2bafd36bc2e7296a14fabd0725.webp?x-oss-process=image/format,png
[format_png 25]: https://img-blog.csdnimg.cn/img_convert/73934232e10a2177661449b4d707f985.webp?x-oss-process=image/format,png
[format_png 26]: https://img-blog.csdnimg.cn/img_convert/2dff39da654d5613d2ed01b3f4915d8f.webp?x-oss-process=image/format,png
[format_png 27]: https://img-blog.csdnimg.cn/img_convert/75948618ab4882e8d565c49395b17e21.webp?x-oss-process=image/format,png
[format_png 28]: https://img-blog.csdnimg.cn/img_convert/214554f405b4b497ed9739101373fc29.webp?x-oss-process=image/format,png
[format_png 29]: https://img-blog.csdnimg.cn/img_convert/ad6e3d75e2aa28b2627ed5f2d173be30.webp?x-oss-process=image/format,png
[format_png 30]: https://img-blog.csdnimg.cn/img_convert/ae77c6f935a98a91c2c97e66a9625034.webp?x-oss-process=image/format,png
[format_png 31]: https://img-blog.csdnimg.cn/img_convert/ffd71b40b226d61b3143fc9597f02264.webp?x-oss-process=image/format,png
[format_png 32]: https://img-blog.csdnimg.cn/img_convert/8a4acafd9af79add75df881d004561ec.webp?x-oss-process=image/format,png
[format_png 33]: https://img-blog.csdnimg.cn/img_convert/3f679e310b54356b2baa756bb40f954b.webp?x-oss-process=image/format,png
[github.com_dsyer_sprin]: https://link.juejin.cn/?target=https%3A%2F%2Fgithub.com%2Fdsyer%2Fspring-boot-allocations
[format_png 34]: https://img-blog.csdnimg.cn/img_convert/748890beccc55628021b3d88e9812da1.webp?x-oss-process=image/format,png
[format_png 35]: https://img-blog.csdnimg.cn/img_convert/b9179669822dec6905a8399d84838db7.webp?x-oss-process=image/format,png