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

别看Spring现在玩的这么花，其实它的“筹码”就两个，“容器”和“bean定义”。

只有先把bean定义注册到容器里，后续的一切可能才有可能成为可能。

所以在进阶的路上如果要想走的顺畅些，彻底搞清楚bean定义注册的所有细节至关重要。

毕竟这是万里长征的第一步。有句话怎么说来着，“勿在浮沙筑高台”。

Spring步入注解和Java配置的时代也有些时日了。而且也旗帜鲜明的表达了bean的注册方法。

这不，就是这个接口，AnnotationConfigRegistry，如下图01：

再来看下这个接口的名字，有三个单词组成，Annotation、Config、Registry。

第一个表示注解，第二个表示Java配置，第三个表示注册。

合起来的意思可以理解为，基于注解和Java配置的bean定义注册。当然，这是我猜的，哈哈哈。

这是一个很牛X的接口，理由见下图02：

纳尼，所有的容器类都实现了它。

不管是web的、非web的，传统Spring的、SpringBoot的，响应式的、Servlet的。

简直是老少通吃、妇孺皆宜啊。淡定、淡定。

这个接口的两个方法非常简约：

一个是直接把一个类（Class<?>）进行注册。

一个是通过扫描指定的包（Package）里的类进行注册。

请注意我刚刚使用了“简约”而没有使用“简单”，因为简约往往并不等于简单，反而更多时候等于难。

讲了这么多，终于可以让今天的主角登场了，来来来，掌声响起来。

就是这两个类：

AnnotatedBeanDefinitionReader

ClassPathBeanDefinitionScanner

第一个类就是站在接口第一个方法register背后默默付出的。

第二个类就是负责搞定接口第二个方法scan后面所有事情的。

下面开始进行具体的讲解，只需要知道都干了什么即可，至于怎么干的，不需要了解。

看第一个类，如下图03：

第一个字段类型是BeanDefinitionRegistry，这是容器（或bean factory）会实现的接口。

用于把一个BeanDefinition（bean定义）注册到容器中，看下它的这个方法，如下图04：

编程新说注：对“bean定义”这个概念不清楚的，可以在文末查看本系列《品Spring》文章的头几篇。

刚刚应该看到在注册bean定义时需要一个bean名称（即beanName），因此该第二个字段发挥作用了。

它就是BeanNameGenerator。例如，有一个类是UserController，它上面标了注解@Controller("user")。

首先它会把注解的value属性作为名称，此时就是user啦。

如果没有指定value属性，就像这样@Controller，此时就是类的短名称且首字母小写，即userController。

这就是bean名称的生成策略，在实际开发中不就是这样的嘛。

第三个字段是ScopeMetadataResolver，是来决定bean实例的范围（即生命周期）的。

常见的生命周期有四种，PROTOTYPE（原型）、SINGLETON（单例）、REQUEST（请求）、SESSION（会话）。

就是通过检查类上有没有@Scope这个注解。如果有的话，就按指定的走，没有的话，就按单例走。

第四个字段是ConditionEvaluator，条件计算器，根据“条件”判断一个bean定义该不该被注册。

这可是SpringBoot自动配置（AutoConfiguration）的基石啊。

就是去检测类上有没有标@Conditional这个注解。如果没有的话，bean定义会被注册。

如果有的话，需要再去计算具体的“条件”，然后才能确定bean定义到底要不要注册。

哎呀，注册一个bean定义好麻烦啊，喘口气，继续吧。嘿嘿。

下面开始真正进入注册的方法，先看下方法的参数吧，如下图05：

方法共有5个参数，只有第一个是必须的，后面的都可以为空。

第一个参数，annotatedClass，是Class<?>，表示要被注册的类。

第二个参数，instanceSupplier，是一个函数式接口，Supplier<T>，可以提供这个bean的实例对象，这样就不再需要通过反射调用构造函数了。

第三个参数，name，bean名称，如果传的话就不用再生成了。

第四个参数，qualifiers，是一组用作限定修饰符的注解，Class<? extends Annotation>[]。

第五个参数，definitionCustomizers，是一组可以自定义bean定义的接口，BeanDefinitionCustomizer。

整个处理过程分为九步，如下图06：

第一步，先把类转变为bean定义，即把Class<?>转变为BeanDefinition。具体是AnnotatedGenericBeanDefinition这个类。

第二步，使用条件计算器来确定是否要注册这个bean定义。

第三步，确定这个bean的生命周期。

第四步，确定这个bean的名称。

第五步，处理定义的公共注解信息。如下图07：

就是@Lazy、@Primary、@DependsOn、@Role、@Description这五个注解。

从类上分别获取这些注解，然后从注解中读出需要的信息，再把这些信息设置到bean定义中。

第六步，处理限定修饰符，就是@Primary、@Lazy、@Qualifier这三个注解。

这个几个注解是从方法参数传入的，上一步的注解是从类上读取的，它们不重复也不冲突。

编程新说注：这些注解的含义和用法，这里就不说了，毕竟这是“追求深度”的文章。

第七步，应用bean定义自定义器，对bean定义进行一些自定义。

第八步，根据bean的生命周期，使用AOP技术为该bean定义生成代理。

第九步，把这个bean定义注册到容器中。

这就是一个bean定义的完整注册过程。妈呀，让我歇会儿。

编程新说注：第二个类注册bean定义的整体逻辑和第一个类完全一样。只是获取bean定义的方式不同。

下面看第二个类，如下图08：

首先可以看到，它扫描的都是jar包中的.class文件。

然后还有两个过滤器集合，决定哪些被排除、哪些被包含。

当然，类中也给出了默认情况下包含的，如下图09：

第一，@Component注解以及用它定义的其它注解，如@Configuration等。

第二，JSR-250里面的@javax.annotation.ManagedBean注解。

第三，JSR-330里面的@javax.inject.Named注解。

标了这三个注解的类都会被注册，第一个注解是Spring的，后两个是Java的。

默认情况下，排除过滤器没有指定，也就是不进行任何显式的排除。

具体收集bean定义的过程，分为七步，如下图10：

第一步，拼接资源路径，形式就是这样classpath*:org/cnt/ts/**/*.class。

它表示搜索类路径下所有的jar包里，以org/cnt/ts开头的包及其子包里的所有.class文件。

第二步，找出上一步中的那些.class文件，并把它们转化为资源，即Resource类。

第三步，使用ASM框架逐个读取这些资源（其实就是字节码文件啦）。

第四步，应用过滤器和条件计算器，来确定这个bean定义是否要被注册。

如下图11：

第五步，使用从字节码中读出的内容来构建BeanDefinition，使用的是ScannedGenericBeanDefinition这个类。

第六步，确认下这个类是否符合要求，如下图12：

一共有三项检查：

第一，必须是独立的。可以是顶级类（非内部类），可以是静态内部类（即static class）。

第二，必须是具体的，即非抽象的。

第三，如果类是抽象的，它必须包含一个标有@Lookup注解的方法，来指定一个具体的bean。

第七步，收集好这个bean定义。

这些bean定义抽取好后，剩下的处理就和第一个类一样了。

如下图13：

也是确定生命周期，生成bean名称，处理定义的公共注解信息，根据生命周期生成代理，最后注册到容器中。

最后声明一点：

以上两个类并不处理@Bean这个注解注册的bean定义，也不处理由@Import注解引入的bean定义。

哪谁处理呢？后续文章见。

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

品Spring：帝国的基石

品Spring：bean定义上梁山

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

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

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

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

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