阅读之前要注意的东西：本文就是主打流水账式的源码阅读，主导的是一个参考，主要内容需要看官自己去源码中验证。全系列文章基于 spring 源码 5.x 版本。

Spring源码阅读系列--全局目录.md

引子

1、容器最基本使用.md

系列1 - bean 标签解析：

2、XmlBeanFactory 的类图介绍.md

3、XmlBeanFactory 对xml文件读取.md

4、xml配置文件解析之【默认】命名空间【标签】的解析.md

5、xml配置文件解析之【自定义】命名空间【标签】的解析.md

系列2 - bean 获取: getBean() 做了什么

前言

一句话概括：

读取 xml 文件中硬编码的各种标签，解析为spring 容器可以识别的形式，并注册到：BeanFactory 中 (BeanDefinitionRegistry)

【只读取配置内容，并注册管理】

1 前文回顾

书接上回，上文终止余如下图所示的位置：

2 bean.xml 实例

既然要真刀真枪的将 xml 文件的标签解析了，那么我们不能继续无实物表演了，下边的例子是从spring 5.x 源码里随机找打的一个 xml 案例：

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN" "https://www.springframework.org/dtd/spring-beans-2.0.dtd">

<beans default-lazy-init="true" default-autowire="constructor" default-merge="true"

       default-init-method="myInit" default-destroy-method="myDestroy">

    <import resource="beanEventsImported.xml"/>

    <alias name="testBean" alias="testBeanAlias1"/>

    <alias name="testBean" alias="testBeanAlias2"/>

    <bean id="testBean" class="org.springframework.tests.sample.beans.TestBean">

        <constructor-arg type="java.lang.String" value="Rob Harrop"/>

        <property name="friends">

            <ref bean="testBean2"/>

        </property>

        <property name="doctor">

            <bean class="org.springframework.tests.sample.beans.NestedTestBean">

                <constructor-arg type="java.lang.String" value="ACME"/>

            </bean>

        </property>

    </bean>

    <bean id="testBean2" class="org.springframework.tests.sample.beans.TestBean">

        <property name="name" value="Juergen Hoeller"/>

        <property name="spouse">

            <bean class="org.springframework.tests.sample.beans.TestBean">

                <property name="name" value="Eva Schallmeiner"/>

            </bean>

        </property>

    </bean>

</beans>

上述作为案例的：beanEvents.xml 文件中包含了，我们在 "默认命名空间" 下所关注的四种标签都有，用来做本文的案例简直再完美不过了。

先来个简单的介绍：

beans：
- 一个beans 包含0到多个 bean、0到多个 import、0到多个 alias，所以对beans 的解析会最终变成对如下几个标签的递归解析
alias：
- bean的别名定义，这个应该是这几个标签最简单的了
bean：
- 这个标签是本文绝对的主角，也是spring系列里的核心角色
- bean 标签，拥有但是不局限于下图所示的直接属性
  - 所谓直接属性就是这种可直接配置的
  - 就算不认识全部，总有眼熟的吧？平时写的注解是不是有出现在下图呢？至于用途就不再赘述了
import：
- 从给出的xml文件案例里也能看出，import就是导入了一个外部定义的 "bean.xml"。
  
  对它的解析会变成对这个外部引入的 "bean.xml" 的递归解析。

3 spring 默认命名空间解析：parseDefaultElement

接下来进入 parseDefaultElement 方法内部，见下图：

方法代码的4个分支，代表的就是 4 中默认命名空间标签的解析，这里重点关注的只有最重要的： bean 标签。

4 关于 bean 标签的解析 processBeanDefinition

这里用红色裱起来了，就说明又到了：关键的代码简单，事情不简单环节了。

4.1 标记的第一行：
- 委托 BeanDefinitionDelegate 类对象,解析 bean 标签的上的属性。
  
  返回值类型：BeanDefinitionHolder 顾名思义，可以把它看作一个 bean 标签配置的相关属性的容器，
  
  至于是哪些属性，后续展开。
4.2 标记第二行：
- 当 bean 标签下边还存在：非spring 官方的支持的，用户自己魔改标签时，需要经过第二行代码，再进行了一轮自定义标签的解析。【不是本文重点关注的内容】
- 如下所示， bean 标签下又有了 mybean 标签，这个一看就不是spring 官方的原装货，所以它需要被单独解析，自定义标签的解析动作被委托给了：
  - delegate.decorateBeanDefinitionIfRequired()

<bean id="test" class="test.xxx.TestXxx">

  <mybean:user userage="22" />

</bean>

4.3 标记第三行
- xml 配置解析结束，解析结果需要注册到：XmlBeanFactory
4.4 标记第四行
- 代表解析动作结束了，这里触发一个响应事件，告知相关的监听器，这个 bean 已经加载成功了。

本章前边提到的四行代码会对应后续的: 【第5 ~ 第8 章】

如果后边忘记了，可以回过头来看看。

5 bean 标签默认属性的解析

本节对应的是 4.1 所标注的那一行代码

这里实际上还没进入正题：

简单的处理下id、name、别名
重点是标注出来的那一行代码
- 上图中，标注的这行代码之后的内容也挺简单的，就是判断 beanName 若为空将按照一定规则自动生成，就像你用了 @Bean @Service @Compement 等等注解，但是没有指定 name那样，容器会自动生成 beanName

下边说回正题：

看下图中标记的三块代码，它们代表着 [第五章] 的3个小节

5.1 上图标注的第一部分：解析结果的承载者的初始化

上图中，依稀可见这么一行代码：

AbstractBeanDefinition bd = createBeanDefinition(className, parent);

这里创建的 BeanDefinition 对象，就是用来承载，我们bean的配置内容解析结果的。

就像你配置的 xml对象，你自己能直接读懂，但是要让 spring 容器去读它时，spring容器会将这个 xml 文本内容进行翻译，而bd [BeanDefinition] 承载的就是翻译结果。

顺着createBeanDefinition() 方法进去，最终会发现 bd的类型固定是： GenericBeanDefinition，下边是它的类图：

我们还记得 XmlBeanFactory 有个重要的接口：

BeanDefinitionRegistry ，它管理的就是：BeanDefinition。
实际上，BeanDefinitionRegistry 就是以map 的形式，对spring 的配置信息进行保存的。

PS 而到目前为止，我们的所有篇幅都在介绍这个翻译过程，且还没介绍完。

至于为什么敢说它承载了 xml的翻译结果，请看下图所示的 AbstractBeanDefinition 类的所有成员变量，请问是不是很眼熟呢？

拓展讲点东西，AbstractBeanDefinition 实际上有三个子类：

已知 xml 中可以定义: 父/子 bean的关系

RootBeanDefinition：早期版本中，若 bean 没有父bean 则用 RootBeanDefinition
ChildBeanDefinition: 早期版本中用于，若 bean 定义了父bean 则用 ChildBeanDefinition 承载 bean 配置属性
GenericBeanDefinition：他是spring 2.5 版本后提供的一站式 BeanDefinition 服务类
- 我们从当前的spring 5.x 版本的源码中对这个问题，就可以窥见一些东西。
  
  你看上述的 createBeanDefinition() 方法，内部 bd 的实例化就一个选择：GenericBeanDefinition。

瞅瞅：父子bean的例子

5.2 标注的第二部分：bean标签硬编码的 [直接]属性解析

被标注的代码

// 硬编码解析默认的bean属性    所有元素 "属性" 解析

parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);

详情：

        /**

	 * Apply the attributes of the given bean element to the given bean * definition.

	 * @param ele bean declaration element

	 * @param beanName bean name

	 * @param containingBean containing bean definition

	 * @return a bean definition initialized according to the bean element attributes

	 */

	public AbstractBeanDefinition parseBeanDefinitionAttributes(Element ele, String beanName,

			@Nullable BeanDefinition containingBean, AbstractBeanDefinition bd) {

		// 是否单例

		if (ele.hasAttribute(SINGLETON_ATTRIBUTE)) {

			error("Old 1.x 'singleton' attribute in use - upgrade to 'scope' declaration", ele);

		}

		// 作用范围 public class ？

		else if (ele.hasAttribute(SCOPE_ATTRIBUTE)) {

			bd.setScope(ele.getAttribute(SCOPE_ATTRIBUTE));

		}

		else if (containingBean != null) {

			// Take default from containing bean in case of an inner bean definition.

			bd.setScope(containingBean.getScope());

		}

		// 是否抽象abstract

		if (ele.hasAttribute(ABSTRACT_ATTRIBUTE)) {

			bd.setAbstract(TRUE_VALUE.equals(ele.getAttribute(ABSTRACT_ATTRIBUTE)));

		}

		// 懒加载 属性  延迟加载

		String lazyInit = ele.getAttribute(LAZY_INIT_ATTRIBUTE);

		if (isDefaultValue(lazyInit)) {

			lazyInit = this.defaults.getLazyInit();

		}

		bd.setLazyInit(TRUE_VALUE.equals(lazyInit));

		// 是否 autowrie 自动装配

		String autowire = ele.getAttribute(AUTOWIRE_ATTRIBUTE);

		bd.setAutowireMode(getAutowireMode(autowire));

		// depends-on 依赖 属性  依赖检查  spring 3.0 以后弃用

		if (ele.hasAttribute(DEPENDS_ON_ATTRIBUTE)) {

			String dependsOn = ele.getAttribute(DEPENDS_ON_ATTRIBUTE);

			bd.setDependsOn(StringUtils.tokenizeToStringArray(dependsOn, MULTI_VALUE_ATTRIBUTE_DELIMITERS));

		}

		// 自动装配条件、前提  属性   值为 false 时，该bean不会被作为其他bean自动自动装配的候选者，

		// 但是它自身自动装配时，可以使用别的bean作为它自己的候选者

		String autowireCandidate = ele.getAttribute(AUTOWIRE_CANDIDATE_ATTRIBUTE);

		if (isDefaultValue(autowireCandidate)) {

			String candidatePattern = this.defaults.getAutowireCandidates();

			if (candidatePattern != null) {

				String[] patterns = StringUtils.commaDelimitedListToStringArray(candidatePattern);

				bd.setAutowireCandidate(PatternMatchUtils.simpleMatch(patterns, beanName));

			}

		}

		else {

			bd.setAutowireCandidate(TRUE_VALUE.equals(autowireCandidate));

		}

		// primary 属性  (初级、初始)

		if (ele.hasAttribute(PRIMARY_ATTRIBUTE)) {

			bd.setPrimary(TRUE_VALUE.equals(ele.getAttribute(PRIMARY_ATTRIBUTE)));

		}

		// 初始化方法  属性。。。

		if (ele.hasAttribute(INIT_METHOD_ATTRIBUTE)) {

			String initMethodName = ele.getAttribute(INIT_METHOD_ATTRIBUTE);

			bd.setInitMethodName(initMethodName);

		}

		else if (this.defaults.getInitMethod() != null) {

			bd.setInitMethodName(this.defaults.getInitMethod());

			bd.setEnforceInitMethod(false);

		}

		// 注销、关闭方法 属性

		if (ele.hasAttribute(DESTROY_METHOD_ATTRIBUTE)) {

			String destroyMethodName = ele.getAttribute(DESTROY_METHOD_ATTRIBUTE);

			bd.setDestroyMethodName(destroyMethodName);

		}

		else if (this.defaults.getDestroyMethod() != null) {

			bd.setDestroyMethodName(this.defaults.getDestroyMethod());

			bd.setEnforceDestroyMethod(false);

		}

		if (ele.hasAttribute(FACTORY_METHOD_ATTRIBUTE)) {  // factory-method 属性

			bd.setFactoryMethodName(ele.getAttribute(FACTORY_METHOD_ATTRIBUTE));

		}

		if (ele.hasAttribute(FACTORY_BEAN_ATTRIBUTE)) {  // factory-bean 属性

			bd.setFactoryBeanName(ele.getAttribute(FACTORY_BEAN_ATTRIBUTE));

		}

		return bd;

	}

5.3 标注的第三块代码：bean标签 - 子标签属性解析

我们重新把那张图请回来：

看原谅色的注解

5.3.1 子标签属性用法介绍

1)、 meta:

元数据, 看图中案例，就是些键值对形式配置的数据；

元数据并非 bean 配置的 class 的属性，它是一个额外的声明；

需要使用时，通过 BeanDefinition 的 getAttribute(key) 方法获取。
2)、 lookup-method:
- 这个属性用得实际是使用比较少，看下边的案例：
  - id="lookUpTest" 的bean配置的 class是抽象类：LookUpTest.java（理论上来说抽象类是不能被实例化的）。
    
    但是按下边的方法配置后，你会发现：
    
    当你通过容器调用如下代码：并不会报错：
    
    LookUpTest obj = (LookUpTest) new XmlBeanFactory("lookUpTest.xml").getBean("lookUpTest")
    
    obj.execute();
    
    这里execute() 内部的抽象方法 getUser() 会获取到xml 中配置的id="userBean"的 java.User对象
- 如果你了解设计模式，就知道这里的妙用了
  - 如果是策略模式：我们可以通过xml配置文件，动态决定注入何种算法。
3)、 replaced-method:
- 上一节提到的 lookup-method 动态替换抽象方法返回的bean；
- 而replaced-method 动态替换 已经实现的方法 逻辑；
- 看看上图的案例:
  
  它会把 executeBean 的 doSomething() 方法的逻辑替换为：doSomethingReplacer中重写的方法逻辑
- 但是它有个要求：被用来替换的，doSomethingReplacer所属的类必须实现如下接口
- 最终 doSomething 方法的逻辑将会被替换为：reimplement() 方法所执行的逻辑
4)、 constructor:
- 如上图所示，顾名思义，其作用就是将另一个bean配置为当前bean构造函数的入参
property:

图一出，就不用介绍干啥用的了吧？
qualifier:

至于它，就更简单了，可以认为它是，我们在给bean注入属性的时候，指定过滤条件
- 【spring 要求通过同样的beanName，只能匹配到一个满足条件的bean，否则容器将会报错】。
- 回忆下，我们通过注解使用 @Qualifier，其实就是在设置过滤，spring 需要保证，最终满足 qualifier 条件条件的bean只能有一个：
```
@Qualifier("integerRepo")

private Repository<?> integerRepositoryQualifierProvider;
```
qualifier，甚至还支持通过属性进行过滤：
- 假如我们将多个 UserBean 注入了容器，qualifier 支持通过 UserBean的属性进行过滤
如下所示的是 qualifier 的三种配置方式：

<beans>

  <!-- 只通过BeanName=foo222 过滤 -->

  <bean id="foo" class="java.lang.String">

    <qualifier value="foo222" />

  </bean>

  <!-- Bean名称 + Bean类型过滤，常见于多态场景下 -->

  <bean class="org.springframework.beans.factory.xml.QualifierAnnotationTests$Person">

    <qualifier type="QualifierAnnotationTests.SimpleValueQualifier" value="curly"/>

  </bean>

  <!-- Bean类型 + Bean属性过滤 UserBean.name="moe" && UserBean.age="15"   -->

  <bean class="org.springframework.beans.factory.xml.QualifierAnnotationTests$Person">

    <property name="name" value="Moe Jr."/>

    <qualifier type="QualifierAnnotationTests.MultipleAttributeQualifier">

      <attribute key="name" value="moe"/>

      <attribute key="age" value="15"/>

    </qualifier>

  </bean>

</beans>

下图是 qualifier 的一般使用场景：

dataSource 和 dataSource2 明显是同类型的不同bean
假如 location 配置 sql不同时，它们就不能随意混用了
所以可以通过 beanName 不同这一点进行过滤

5.3.2 子标签属性解析源码

上边说完了他们的用法，下边我们说说他们是怎么被，spring 从xml配置文件中识别出来的：

meta:

如图所示，就是通过 key - value 获取 meta标签配置的键值对，

依赖 [key, value] 生成了 BeanMetadataAttribute 实例，最后注入了BeanDefinition中

<?xml version="1.0" encoding="UTF-8"?>

<bean class="org.xxx.xml.QualifierAnnotationTests$Person">

      <meta key="name" value="moe"/>

      <meta key="age" value="42"/>

</bean>

lookup-method:

解析的代码跟meta的解析大同小异。

解析的结束动作，可以视为：就是简单的拿到 lookup-method 标签注入的：抽象方法名称、bean名称

然后通过，MethodOverrides 属性间接注入的 BeanDefinition 中
replaced-method:
constructor:

构造函数参数解析，逻辑稍微长了一丢丢，这里主要是因为，构造函数参数可以设置顺序。

如果设置了顺序[index]，那么需要校验数字是否合规，数字是否重复等等问题，最终将解析的结果注入到了 BeanDefinition 中。
property:

跟上边的解析过程大同小异
qualifier:

到此，bean 标签下的，默认标签、元素的解析完成了

6 默认标签中的自定义标签元素解析

下图所示的是：第四章所述的第二段代码，bean 标签下的自定义标签的解析。

下一篇文章将细讲，这里只做简单的介绍。

遍历读取标签

浅浅的说一下下图的行为：

1 根据标签识别其所属的命名空间
2 跳过 spring 默认命名空间下的标签
3 根据命名空间获取，该非默认命名空间标签的，处理器【NamespaceHandler】

你或许会好奇，怎么突然蹦出个：NamespaceHandler啊，前文并没有任何地方提到它啊？

实际上，NamespaceHandler，由自定义标签的人提供，如果我们自定义了自己的标签

那么我们需要在 spring 解析配置前，去容器中注入我们自己开发的：NamespaceHandler
4 解析非默认命名空间标签【下一篇文章细说，非默认命名空间 - 标签，的解析】

7 BeanDefinition 的注册

将前文解析到的 BeanDefinition 注册到，容器中。

经过前文介绍可知， XmlBeanFactory 继承了一个接口，没错，就是下图所述的接口：

BeanDefinitionRegistry

这个接口负责对 BeanDefinition 信息的管理。

继续跟踪上图中的

registerBeanDefinition() 方法，来到此行的终点,
已知 BeanDefinitionReaderUtils.registerBeanDefinition() 的参数：

BeanDefinitionRegistry registry是个接口，那么上哪去找它的实现类呢？当然是：

XmlBeanFactory 的类图了：这下该知道方法实现在哪了吧？

下边代码中最核心的一句代码：

this.beanDefinitionMap.put(beanName, beanDefinition);

这就是说：BeanDefinitionRegistry 通过 Map 以键值对形式管理beanDefinition 的直接证据。

    // 通过 beanName 注册/记录

	@Override

	public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)

			throws BeanDefinitionStoreException {

		// 空校验

		Assert.hasText(beanName, "Bean name must not be empty");

		Assert.notNull(beanDefinition, "BeanDefinition must not be null");

		// 是否是AbstractBeanDefinition 子类

		if (beanDefinition instanceof AbstractBeanDefinition) {

			try {

				//  注册前最后一次校验，不同于xml校验

				//  它是对 类定义的（AbstractBeanDefinition）  methodOverrides属性的校验

				//  校验其是否于工厂方法并存、   是否存在(??)

				((AbstractBeanDefinition) beanDefinition).validate();

			}

			catch (BeanDefinitionValidationException ex) {

				throw new BeanDefinitionStoreException(beanDefinition.getResourceDescription(), beanName,

						"Validation of bean definition failed", ex);

			}

		}

		BeanDefinition existingDefinition = this.beanDefinitionMap.get(beanName);

		//  检查是否已经注册

		if (existingDefinition != null) {

			//  已注册

			if (!isAllowBeanDefinitionOverriding()) {//  不允许覆盖，抛出异常

				throw new BeanDefinitionStoreException(beanDefinition.getResourceDescription(), beanName,

						"Cannot register bean definition [" + beanDefinition + "] for bean '" + beanName +

						"': There is already [" + existingDefinition + "] bound.");

			}

			else if (existingDefinition.getRole() < beanDefinition.getRole()) {//   bean 的应用(？？范围？？) 变化

				// e.g. was ROLE_APPLICATION, now overriding with ROLE_SUPPORT or ROLE_INFRASTRUCTURE

				if (logger.isWarnEnabled()) {

					logger.warn("Overriding user-defined bean definition for bean '" + beanName +

							"' with a framework-generated bean definition: replacing [" +

							existingDefinition + "] with [" + beanDefinition + "]");

				}

			}

			else if (!beanDefinition.equals(existingDefinition)) {//  关键信息变化，不能视作同一个bean ??

				if (logger.isInfoEnabled()) {

					logger.info("Overriding bean definition for bean '" + beanName +

							"' with a different definition: replacing [" + existingDefinition +

							"] with [" + beanDefinition + "]");

				}

			}

			else {

				if (logger.isDebugEnabled()) {

					logger.debug("Overriding bean definition for bean '" + beanName +

							"' with an equivalent definition: replacing [" + existingDefinition +

							"] with [" + beanDefinition + "]");

				}

			}

			//  类定义BeanDefinition 维护到线程安全的 Map 中

			this.beanDefinitionMap.put(beanName, beanDefinition);

		}

		else {

			//  还未注册过

			if (hasBeanCreationStarted()) {

				// Cannot modify startup-time collection elements anymore (for stable iteration)

				synchronized (this.beanDefinitionMap) {

					this.beanDefinitionMap.put(beanName, beanDefinition);  //  维护map

					List<String> updatedDefinitions = new ArrayList<>(this.beanDefinitionNames.size() + 1);

					updatedDefinitions.addAll(this.beanDefinitionNames);

					updatedDefinitions.add(beanName);

					this.beanDefinitionNames = updatedDefinitions;

					if (this.manualSingletonNames.contains(beanName)) {

						Set<String> updatedSingletons = new LinkedHashSet<>(this.manualSingletonNames);

						updatedSingletons.remove(beanName);

						this.manualSingletonNames = updatedSingletons;

					}

				}

			}

			else {

				// Still in startup registration phase

				this.beanDefinitionMap.put(beanName, beanDefinition);

				this.beanDefinitionNames.add(beanName);

				this.manualSingletonNames.remove(beanName);

			}

			this.frozenBeanDefinitionNames = null;

		}

		if (existingDefinition != null || containsSingleton(beanName)) {

			resetBeanDefinition(beanName);

		}

		else if (isConfigurationFrozen()) {

			clearByTypeCache();

		}

	}

8 触发响应事件

再看事件监听器，没错它是从 XmlBeanDefinitionReader 中注入的，你看世界又闭环了。

【PS * 到了这里，你可能已经忘了 XmlBeanDefinitionReader是谁了，不急我来给你重新介绍下：】

你看下图的setter 方法，这里明显是支持注入自定义监听器的，没有自定义则直接注入默认的监听器。

9 结语

9.1 前文总结

到此，本文终于结束了，spring 默认命名空间下的标签已经解析结束了。

至此，BeanDefinitionRegistry 中已经注册好了 BeanDefinition 的信息了；后续，在 getBean() 的流程中， BeanDefinitionRegistry 中注册的 BeanDefinition 将再次粉墨登场。

<如果你不关注：第三方定义的命名空间怎么解析；你可以跳过下一篇文章，直接看getBean 到底干了啥了>

回顾下，本文提到了spring 的4个标签，我们用了绝大部分的篇幅在讲， bean 标签及其子标签、属性的解析，是因为另外的三个标签不重要吗？

是的，它们不重要。而且它们的解析过程，要么极其简单，要么就是对 bean 标签解析的套娃[递归] 应用，所以这里讲 bean 标签的解析就已经达到目的了。
如果，你看完了bean 标签解析，还看不懂另外三个标签的解析，那么你需要注意，你是否进度拉太快了，之前的内容你消化了么？

————————

beans: 它的实质就是递归调用 bean 标签的解析过程

alias: 为bean注册别名，方便同一个bean可以通过不同的beanName 来引用，代码也简单就不展开了

bean: 老熟人了，不解释

import: 下图就是 import 标签的解析，看看标注的那行代码？是不是一眼顶针？小黑子在每个地方都会非常的显眼。

getReaderContext().getReader() 获取的不就是当前 XmlBeanFactory 上的 XmlBeanDefinitionReader 么？

所以，世界又重启了呀，我们又回答了苹果摊前

至于 XmlBeanFactory 不需要介绍了吧？再问紫纱。