品Spring：SpringBoot发起bean定义注册的“二次攻坚战”

上一篇文章整体非常轻松，因为在容器启动前，只注册了一个bean定义，就是SpringBoot的主类。

OK，今天接着从容器的启动入手，找出剩余所有的bean定义的注册过程。

具体细节肯定会颇为复杂，同样，大家只需关注都干了什么，不用考虑如何干的。

来宏观的看下容器的启动过程，即refresh方法，如下图01：

只捡重要的来说，就是四大步：

第一，准备好bean工厂（BeanFactory）。

第二，调用已经注册的bean工厂后处理器（BeanFactoryPostProcessor）。

第三，注册bean后处理器（BeanPostProcessor）。

第四，实例化所有的单例bean。

其中第二、第三引入两个新概念，“bean工厂后处理器”和“bean后处理器”。

为了更好的理解它们，再来赘述一遍和bean相关的操作过程。

注册bean定义 -> ① -> 实例化bean -> 依赖的装配 -> ② -> 初始化bean -> ③ -> OK

这个就是从一开始到bean实例准备好的整个流程。其中①②③是Spring预留的三个埋点，可以在这些地方插入一些用户代码，进行一些定制化。

其中①位于bean定义已经注册好后，尚未开始生成bean实例时，此处就是用来自定义处理bean定义的。

剩余②和③位于bean实例的初始化方法执行之前和之后，此处就是用来自定义处理bean实例的。

所以①处就对应于上述的第二，即bean工厂后处理器。②和③处就对应于上述的第三，即bean后处理器。

因此，可以看出，在容器启动过程中，能够和bean定义搭上关系的只有上述的第二，就是bean工厂后处理器。

它就是接下来我们的突破口。可是会有人问，从一开始到现在，明明没有人注册过它，为什么这里会调用它呢？

咦，这个问题问的好。不妨倒推一下，首先，肯定是注册了这个bean工厂后处理器了，不然这里为啥要调用，不然剩余的那些bean定义是如何注册到容器里的？

既然我们（即用户代码）没有注册，那一定是系统（即框架代码）自动注册了。好吧，只能姑且这样认为了。

那就找吧，肯定是隐藏在了某个地方。找啊找啊找朋友，找找找。

终于，功夫不负有心人，找到了，它隐藏在了两个类中，就是两个负责注册bean定义的类。

AnnotatedBeanDefinitionReader这个类的构造函数中，如下图02：

ClassPathBeanDefinitionScanner这个类的scan方法中，如下图03：

我们发现它们执行的是相同的代码，这不就执行两遍了吗？哈哈，里面做了幂等处理啦。

进到这个方法里会发现注册了好几个bean，但是bean工厂处理器的只有一个，如下图04：

它的bean名称里带了个internal，说明是内部使用的，即“基础设施”的作用，如下图05：

这个类的名称以ConfigurationClass开头，表示是对标有@Configuration注解的类的全权处理。

仔细想一下，让你在Spring家族中选择一个最特殊、最常见的注解，任何人都会选择@Configuration这个注解。

再仔细体会下，这个注解其实具有类似“配置”和“管理”方面的功能。可以说整个Spring都是围绕着它构建起来的。

OK，现在即将迎来本文的核心内容，打起精神来。照例还是侧重整体过程，弱化具体实现细节。

第一，取出已经注册的bean定义，其实就是主类自己这个光杆司令。

第二，判断它是否需要被处理，满足的条件是：

1）标有@Configuration注解

2）标有@Component注解

3）标有@ComponentScan注解

4）标有@Import注解

5）标有@ImportResource注解

6）含有@Bean方法

只要这六个条件满足其一，就需要被处理。

由于SpringBoot的主类上标有@SpringBootApplication注解，所以上述第1条就已满足了。

因此主类需要被处理，这不废话嘛，目前只注册了它自己，必须的被处理啊。

编程新说注：每一个符合条件的类，都可以认为是一个源（Source，即源泉），它的作用就是向容器中贡献bean定义。

第三，如果类上标有@Component注解，就去处理它的静态内部（嵌套）类，如下图06：

这其实已经是递归了，所以处理方式是一样的。

第四，接着处理@PropertySource注解，它可以引入.properties文件，会把文件中的属性值放入到Environment中。如下图07：

第五，接着处理@ComponentScan注解，它会扫描指定的jar包，并从中获取bean定义，如下图08：

第六，然后再处理@Import注解，如下图09：

该注解共可以引入三类内容：

1）另一个普通类，但是当作@Configuration类

2）ImportSelector接口的实现类

3）ImportBeanDefinitionRegistrar接口的实现类

其中第2、3是通过实现接口，自己写代码来注册bean定义，超级灵活，随意掌控。

编程新说注：这种方式的一般典型用法是，在实现第三方框架和Spring框架整合时使用。

请看下代码，如下图10：

第七，然后处理@ImportResource注解，它用于引入.xml文件，可以使xml和注解两种方式混合使用，如下图11：

第八，然后再处理类中的@Bean方法，如下图1213：

第九，然后再处理接口里面的默认方法，且方法上有@Bean注解的，如下图1415：

第十，最后再处理父类，如下图16：

因为每个@Configuration类除了自身是源之外，还可以向容器贡献其它的源，所以总体是递归进行的。

在进行的过程中，做好了防重复处理，所以不会出现重复注册。

以上所有这些其实都是ConfigurationClassPostProcessor这类里面的逻辑。

它不仅仅是一个bean工厂后处理器，还是一个专门用于注册bean定义的后处理器。

这个类在容器启动时会被调用，因此把其它类的bean定义注册到了容器中。

>>> 品Spring系列文章 <<<

品Spring：帝国的基石

品Spring：bean定义上梁山

品Spring：实现bean定义时采用的“先进生产力”

品Spring：注解终于“成功上位”

品Spring：能工巧匠们对注解的“加持”

品Spring：SpringBoot和Spring到底有没有本质的不同？

品Spring：负责bean定义注册的两个“排头兵”

品Spring：SpringBoot轻松取胜bean定义注册的“第一阶段”

作者是工作超过10年的码农，现在任架构师。喜欢研究技术，崇尚简单快乐。追求以通俗易懂的语言解说技术，希望所有的读者都能看懂并记住。下面是公众号和知识星球的二维码，欢迎关注！