Spring源码之——有BeanDefinition才有Bean

我们知道Spring的可用通过多种方式进行配置：XML配置文件、Groovy配置文件、注解配置、Java代码配置。无论什么样的形式的配置都要先被解析成初始化Bean所需要的各种元信息（Metadata），也就是BeanDefinition对象

我们重点关注org.springframework.context.support.AbstractApplicationContext#refresh中调用的

注释写的简单，告诉子类来刷新内部的beanFactory，返回被刷新的BeanFactory实例

getBeanFactory就是返回已经实例化好的beanFactory，比较简单。所以我们重点关注refreshBeanFactory

以上，很清楚的看到创建刷新BeanFactory的几个关键事项：

1.创建BeanFactory实例 createBeanFactory()

2.留给子类扩展，对BeanFactory做一些个性化设置 customizeBeanFactory(beanFactory)

3.加载BeanDefinition loadBeanDefinitions(beanFactory)

BeanFactory的实例化

先来看BeanFactory的创建

注释写的很清楚，为context创建一个beanFactory，因为创建的是DefaultListableBeanFactory的实例，在下一步customizeBeanFactory(beanFactory)中，我们就可以调用它的一些方法来设置是否允许BeanDefinition定义覆盖、是否允许循环引用等，然后在AbstractAutowireCapableBeanFactory的构造器中，设置了几个Aware类的依赖注入检查

在AbstractAutowireCapableBeanFactory中设置了父BeanFactory（如果有的话）

还记得我们创建的BeanFactory是new的那个子类吗？对，是``，我们也可以通过类图来大概看一下它具备那些能力和属性

解释一个几个Registry（注册器）

•AliasRegistry 要求子类实现提供别名的管理能力（注册、查询等接口）

•BeanDefinitionRegistry 要求子类实现提供BeanDefinitition的管理能力

•SingletonBeanRegistry 要求子类实现提供单例Bean的管理能力
所有new出来的这个DefaultListableBeanFactory就必定有这些相关的接口

对BeanFactory的个性化设置

上面已经提到过了，我们列举几个典型的可被覆盖的BeanFactory属性

•setAllowBeanDefinitionOverriding 是否允许BeanDefinition覆盖，有多个配置来源时可能会产生命名冲突等，这个设置也对Bean的别名覆盖生效。为false时，如果有冲突会抛异常

•setAllowCircularReferences 是否允许Bean之间的循环引用，为true时（默认）会自动解决循环依赖

•setAllowRawInjectionDespiteWrapping 是否允许原始Bean（没有切面和装饰）的注入，默认FALSE，不那么常用，也不鼓励使用

•setAllowEagerClassLoading 是否允许Bean的Class提前加载，及时被标识为lazy-init，默认true

加载BeanDefinition

自此，我们就已经得到了一个BeanFactory对象，这之后，我们将使用BeanFactory实例完成一系列的后续工作。在refreshBeanFactory中，则有非常重要的一步——loadBeanDefinitions(beanFactory)，这里面的源码真的是很庞大，我们还是挑重点进行讲解。

继续看 loadBeanDefinitions(beanDefinitionReader)的核心逻辑

下面就进入了XmlBeanDefinitionReader的加载逻辑中

加载多个资源，便有加载单个资源接口，直接看

转化成String location转化成 Resource之后继续下钻 - loadBeanDefinitions(resources)

并且会继续遍历后执行 loadBeanDefinitions(new EncodedResource(resource));

EncodedResource加上了编码和字符集信息，继续下钻至 doLoadBeanDefinitions(inputSource, encodedResource.getResource())

这里加上2个标题，之前都跳过也没有关系，核心的就是这里的逻辑：

将配置信息Resource读取成Document对象中，并根据该Document对象将资源注册到Bean工厂中

•doLoadDocument(inputSource, resource)

•registerBeanDefinitions(doc, resource)

继续看，又是将处理逻辑委托给BeanDefinitionDocumentReader实例的方法 registerBeanDefinitions，搞不清这是装饰器模式，还是适配器模式，还是代理模式。。。

先看DefaultBeanDefinitionDocumentReader的实现吧

protectedvoidparseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
//
if (delegate.isDefaultNamespace(root)) {
NodeList nl = root.getChildNodes();
for&nbsp;(int&nbsp;i = 0; i < nl.getLength(); i++) {

进去看下

我们在上面铁锅BeanFactory的类图，实现了BeanDefinitionRegistry和AliasRegistry，所以传进来的就是BeanFactory对象了

这样兜一大圈子有啥好处呢？这样理解起来也贼复杂了

这就是面向接口编程了，每一层只负责自己职责内的逻辑，其他的逻辑我只调用接口引用的方法就可以了，你给我什么实现，就会调用谁的实现。扩展性就好了嘛

因为我们知道不同的环境下，很多的变话，比如：

2.配置文件的读取逻辑不同，所以要用不同的Reader

3.BeanFactory的具体实现类也可能有所不同

回到BeanFactory再看，BeanDefinition是怎么被加载的，进入

这里的逻辑就蛮简单的，BeanDefinition列表都已经拿到了，就注册上去好了（忽略的和没有提到的代码无非就是检查重复、判断是否已经有同名的单例Bean存在了，都销毁、刷新或重置下）

至此，就完成了BeanFactory的实例化，基础设置工作和BeanDefinition加载工作，因为笔者使用的是XML的配置文件，在最终的BeanDefinition加载前经过XmlBeanDefinitionReader中的BeanDefinitionDocumentReader处理，并交由BeanDefinitionParserDelegate完成配置资源加载成Document并解析成BeanDefinition，并由BeanDefinitionReaderUtils调用BeanDefinitionRegistry实例（也就是BeanFactory实例）完成BeanDefinition的注册。

https://blog.csdn.net/mytream/article/details/124892899

也可以前往（请给我一根烟的时间https://blog.csdn.net/mytream）查看更多个人心得和分享，和笔者一起互相讨论