本文接上一篇文章 阅读Spring源码：IOC控制反转前的处理，继续进行下面的分析
首先贴出 Spring bean容器的刷新的核心 11个步骤进行祭拜(一定要让我学会了…阿门)
// 完成IoC容器的创建及初始化工作
@Override
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
// 1： 刷新前的准备工作。
prepareRefresh();
// 告诉子类刷新内部bean 工厂。
// 2：创建IoC容器（DefaultListableBeanFactory）,加载解析XML文件（最终存储到Document对象中）
// 读取Document对象，并完成BeanDefinition的加载和注册工作
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// 3： 对IoC容器进行一些预处理（设置一些公共属性）
prepareBeanFactory(beanFactory);
try {
// 4: 允许在上下文子类中对bean工厂进行后处理。
postProcessBeanFactory(beanFactory);
// 5： 调用BeanFactoryPostProcessor后置处理器对BeanDefinition处理
invokeBeanFactoryPostProcessors(beanFactory);
// 6： 注册BeanPostProcessor后置处理器
registerBeanPostProcessors(beanFactory);
// 7： 初始化一些消息源（比如处理国际化的i18n等消息源）
initMessageSource();
// 8： 初始化应用事件多播器
initApplicationEventMulticaster();
// 9： 初始化一些特殊的bean
onRefresh();
// 10： 注册一些监听器
registerListeners();
// 11： 实例化剩余的单例bean（非懒加载方式）
// 注意事项：Bean的IoC、DI和AOP都是发生在此步骤
finishBeanFactoryInitialization(beanFactory);
// 12： 完成刷新时，需要发布对应的事件
finishRefresh();
}
catch (BeansException ex) {
if (logger.isWarnEnabled()) {
logger.warn("Exception encountered during context initialization - " +
"cancelling refresh attempt: " + ex);
}
// 销毁已经创建的单例避免占用资源
destroyBeans();
// 重置'active' 标签。
cancelRefresh(ex);
// 传播异常给调用者
throw ex;
}
finally {
// 重置Spring核心中的常见内省缓存，因为我们可能不再需要单例bean的元数据了...
resetCommonCaches();
}
}
}
下面来分析上述流程中的第二个步骤：创建并解析IOC容器
我们开始进入分析，首先会调用到 AbstractApplicationContext 中的 obtainFreshBeanFactory 方法，此方法会进行IOC容器的刷新并取出BeanFactory，代码如下
// 告诉内部子类刷新内部的bean factory
protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
// 主要是通过该方法完成IoC容器的刷新
// ClassPathXmlApplicationContext.refreshBeanFactory 调用的是 AbstractRefreshApplicationContext
// AnnotationConfigApplicationContext.refreshBeanFactory调用的是GenericApplicationContext
refreshBeanFactory();
ConfigurableListableBeanFactory beanFactory = getBeanFactory();
...
return beanFactory;
}
1.首先第一步， refreshBeanFactory，刷新Bean工厂，refreshBeanFactory是一个接口，此接口在 AbstractApplicationContext 中进行定义，先看一下这个JavaDoc对这个接口的定义
/**
* 子类必须实现这个方法才能执行实际的配置加载。此方法在任何其他初始化工作开始之前由refresh()方法调用
* 一个子类创建了一个新的 bean factory 并且持有对它的引用，或者返回它拥有的单个BeanFactory实例。
* 在后一种情况下，如果多次刷新上下文，它通常会抛出 IllegalStateException。
*/
protected abstract void refreshBeanFactory() throws BeansException, IllegalStateException;
它有两个实现类，默认的是 AbstractRefreshableApplicationContext 类，它的refreshBeanFactory方法如下
@Override
protected final void refreshBeanFactory() throws BeansException {
// 如果之前有IoC容器，则销毁
if (hasBeanFactory()) {
destroyBeans();
closeBeanFactory();
}
try {
// 创建IoC容器，也就是 DefaultListableBeanFactory, 初始化AbstractBeanFactory
// 注册BeanNameAware,BeanClassLoaderAware,BeanFactoryAware, 设置当前BeanFactory
DefaultListableBeanFactory beanFactory = createBeanFactory();
beanFactory.setSerializationId(getId());
// 设置工厂的属性：是否允许BeanDefinition覆盖和是否允许循环依赖
customizeBeanFactory(beanFactory);
// 调用载入BeanDefinition的方法，在当前类中只定义了抽象的loadBeanDefinitions方法，具体的实现调用子类容器
loadBeanDefinitions(beanFactory);
synchronized (this.beanFactoryMonitor) {
this.beanFactory = beanFactory;
}
}
catch (IOException ex) {
throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex);
}
}
如果之前有IOC容器的话，就进行销毁，并且关闭容器。适用于第二次调用ClassPathXmlApplicationContext("配置文件")，由于是第一次加载配置文件，还未创建BeanFactory，所以hasBeanFactory()返回false。
下面这一步就是创建IOC容器，也就是DefaultListableBeanFactory
// 为上下文创建一个内部工厂，默认的实现创建了一个内部的DefaultListableBeanFactory.getInternalParentBeanFactory()，
// 在子类中被重写，例如自定义DefaultListableBeanFactory的设置。
protected DefaultListableBeanFactory createBeanFactory() {
return new DefaultListableBeanFactory(getInternalParentBeanFactory());
}
上述方法传递的是一个getInternalParentBeanFactory()方法，我们先来看一下这个方法：
protected BeanFactory getInternalParentBeanFactory() {
return (getParent() instanceof ConfigurableApplicationContext) ?
((ConfigurableApplicationContext) getParent()).getBeanFactory() : getParent();
}
getParent()这个方法会返回父类上下文，如果没有(父类)的话，返回null(也就表明这个上下文是继承树的根节点。)这句代码的意思也就是说如果它实现了 ConfigurableApplicationContext，则返回父类上下文的BeanFactory，如果没有的话，就返回父上下文本身。因为没有设置过父节点上下文，所以此时的getInternalParentBeanFactory()方法返回为null。
下一步返回一个DefaultListableBeanFactory，首先来看一下DefaultListableBeanFactory的继承体系
它的调用流程如下：
在
AbstractRefreshableApplicationContext类中返回一个DefaultListableBeanFactory的构造函数DefaultListableBeanFactory构造函数中调用AbstractAutowireCapableBeanFactory的构造函数AbstractAutowireCapableBeanFactory带参数的构造函数会调用AbstractAutowireCapableBeanFactory无参数的构造函数，并注册了BeanNameAware、BeanFactoryAware、BeanClassLoaderAware接口。并设置setParentBeanFactory(parentBeanFactory) 为null（parentBeanFactory就是上面getInternalParentBeanFactory()方法的返回值）;
AbstractAutowireCapableBeanFactory会调用父类AbstractBeanFactory无参构造方法并初始化。
此时的DefaultListableBeanFactory会带上一系列的初始化字段。Bean工厂说的也就是DefaultListableBeanFactory
2.在createBeanFactory()之后，会给ClassPathXmlApplicationContext设置全局唯一Id
beanFactory.setSerializationId(getId());
3.第三步，设置DefaultListableBeanFactory的属性，是否允许重写Bean的定义信息和是否允许循环依赖。没有设置，默认为null
/*
* 通过上下文自定义内部bean工厂。 尝试调用每一个refresh 方法。
* 默认实现应用此上下文setAllowBeanDefinitionOverriding 是否允许Bean定义重写
* 和 setAllowCircularReferences 是否允许循环依赖设置。
* 如果特殊情况，可以在子类中重写以任何自定义DefaultListableBeanFactory 设置。
*/
protected void customizeBeanFactory(DefaultListableBeanFactory beanFactory) {
if (this.allowBeanDefinitionOverriding != null) {
beanFactory.setAllowBeanDefinitionOverriding(this.allowBeanDefinitionOverriding);
}
if (this.allowCircularReferences != null) {
beanFactory.setAllowCircularReferences(this.allowCircularReferences);
}
}
4.最关键的一步，加载Bean的定义信息。所有关于Bean Definitions都会在这一步的这个方法进行解析。调用载入BeanDefinition的方法，在当前类中只定义了抽象的loadBeanDefinitions方法，具体的实现调用子类容器AbstractXmlApplicationContext 中的loadBeanDefinitions方法，具体代码如下
// 通过XmlBeanDefinitionReader 加载bean 定义信息。
@Override
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
// 创建一个BeanDefinition阅读器，通过阅读XML文件，真正完成BeanDefinition的加载和注册
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
// 配置bean 定义阅读器和上下文资源加载环境。
beanDefinitionReader.setEnvironment(this.getEnvironment());
beanDefinitionReader.setResourceLoader(this);
beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
// 允许子类提供自定义初始化的reader，然后继续加载bean定义信息。
initBeanDefinitionReader(beanDefinitionReader);
// 委托给BeanDefinition阅读器去加载BeanDefinition
loadBeanDefinitions(beanDefinitionReader);
}
首先来看第一步，创建XmlBeanDefinitionReader并进行BeanDefinition的加载和注册。初始化XmlBeanDefinitionReader(beanFactory)构造方法，然后调用AbstractBeanDefinitionReader（BeanDefinitionRegistry registry）的构造方法，因为DefaultListableBeanFactory实现了BeanDefinitionRegistry接口，所以就把DefaultListableBeanFactory当作一个BeanDefinitionRegistry传递进去。下面看代码
/* 通过bean 工厂创建一个新的 AbstractBeanDefinitionReader。
如果传入的bean 工厂不仅实现了BeanDefinitionRegistry 接口还实现了ResourceLoader 接口。
将会使用默认的ResourceLoader。 这是 ApplicationContext 实现的情况。
如果给定一个普通的BeanDefinitionRegistry，则默认的 ResourceLoader 会是PathMatchingResourcePatternResolver
如果传入的bean 工厂实现了 EnvironmentCapable，则此读取器将使用此环境。否则，这个读取器
将会初始化并且使用 StandardEnvironment。 所有ApplicationContext的实现都是 EnvironmentCapable，
然而通常BeanFactory 的实现则不是。
*/
protected AbstractBeanDefinitionReader(BeanDefinitionRegistry registry) {
...
if (this.registry instanceof ResourceLoader) {
this.resourceLoader = (ResourceLoader) this.registry;
}
else {
this.resourceLoader = new PathMatchingResourcePatternResolver();
}
if (this.registry instanceof EnvironmentCapable) {
this.environment = ((EnvironmentCapable) this.registry).getEnvironment();
}
else {
this.environment = new StandardEnvironment();
}
}
上面代码的意思就是，如果BeanDefinitionRegistry实现了ResourceLoader接口，就会强制转换为ResourceLoader，否则，将会new 一个PathMatchingResourcePatternResolver()，如果实现了EnvironmentCapable接口，就直接获取系统环境，否则就直接new一个StandardEnvironment。
完成第一步之后，然后配置bean阅读器和上下文资源加载环境，允许子类提供自定义初始化的reader，然后继续加载bean定义信息。这一步希望子类实现自定义的bean加载信息。
最后一步进行真正意义上当bean加载，委托给BeanDefinition阅读器去加载BeanDefinition，来看具体的解析过程
// 委托给XmlBeanDefinition阅读器去加载BeanDefinition
// loadBeanDefinitions(beanDefinitionReader); ↓
@Override
public int loadBeanDefinitions(Resource resource) throws BeanDefinitionStoreException {
// 将读入的XML资源进行特殊编码处理
return loadBeanDefinitions(new EncodedResource(resource));
}
// loadBeanDefinitions ↓
// loadBeanDefinitions(resources) 经过一系列的调用最终会调用到下面的代码
// XmlBeanDefinitionReader 部分代码省略
public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {
...
// 从InputStream中得到XML的解析源
InputSource inputSource = new InputSource(inputStream);
if (encodedResource.getEncoding() != null) {
inputSource.setEncoding(encodedResource.getEncoding());
}
// 这里是具体的读取过程
return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
}
// doLoadBeanDefinitions ↓
protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
throws BeanDefinitionStoreException {
// 通过DOM4J加载解析XML文件，最终形成Document对象
Document doc = doLoadDocument(inputSource, resource);
// 通过对Document对象的操作，完成BeanDefinition的加载和注册工作
return registerBeanDefinitions(doc, resource);
}
// registerBeanDefinitions ↓
public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {
// 创建BeanDefinitionDocumentReader来解析Document对象，完成BeanDefinition解析
BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();
// 获得容器中已经注册的BeanDefinition数量
int countBefore = getRegistry().getBeanDefinitionCount();
// 解析过程入口，BeanDefinitionDocumentReader只是个接口，具体的实现过程在DefaultBeanDefinitionDocumentReader完成
documentReader.registerBeanDefinitions(doc, createReaderContext(resource));
// 统计新的的BeanDefinition数量
return getRegistry().getBeanDefinitionCount() - countBefore;
}
到这一步仍旧只是创建了各种需要解析的阅读器对象，文档解析对象，解析之前的准备工作，
这里说一下BeanDefinitionDocumentReader 这个接口：
/*
* 每个要解析的文档实例化：实现可以在执行
* registerBeanDefinitions 方法时保存实例变量中的状态
* 例如，为文档中的所有bean定义定义的全局设置。
*/
public interface BeanDefinitionDocumentReader {
/*
* 从 DOM 文档中读取Bean 定义信息并且通过阅读器上下文环境把它们注册进registry中
*/
void registerBeanDefinitions(Document doc, XmlReaderContext readerContext)
throws BeanDefinitionStoreException;
}
它的默认实现类只有一个，就是 DefaultBeanDefinitionDocumentReader ，此类负责做真正的bean 解析工作。
下面registerBeanDefinitions之后的方法会完成真正的bean解析工作：
DefaultBeanDefinitionDocumentReader.java
// 这个实现用来解析 spring-beans 约束
// 打开DOM 文档，初始化默认<beans/>的设置；然后解析其中的bean定义信息。
@Override
public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {
this.readerContext = readerContext;
logger.debug("Loading bean definitions");
// 获得Document的根元素<beans>标签
Element root = doc.getDocumentElement();
// 真正实现BeanDefinition解析和注册工作
doRegisterBeanDefinitions(root);
}
// doRegisterBeanDefinitions(root); ↓
protected void doRegisterBeanDefinitions(Element root) {
/*
任何嵌套的<beans>元素都将导致此方法中的递归。 为了正确传播和保留<beans>default-* 属性，跟踪当前的
父委托，可能为null。
创建新的（子）委托，引用父项以进行回退，然后最终将this.delegate重置为其原始（父）引用。 此行为模拟了一堆代理，而实际上并不需要一个代理。
*/
// 这里使用了委托模式，将具体的BeanDefinition解析工作交给了BeanDefinitionParserDelegate去完成
BeanDefinitionParserDelegate parent = this.delegate;
this.delegate = createDelegate(getReaderContext(), root, parent);
// 判断该根标签是否包含http://www.springframework.org/schema/beans默认命名空间
...
// 在解析Bean定义之前，进行自定义的解析，增强解析过程的可扩展性
preProcessXml(root);
// 委托给BeanDefinitionParserDelegate,从Document的根元素开始进行BeanDefinition的解析
parseBeanDefinitions(root, this.delegate);
// 在解析Bean定义之后，进行自定义的解析，增加解析过程的可扩展性
postProcessXml(root);
this.delegate = parent;
}
看到这里已经真心不容易了，需要休息一下吗？怎么说呢，源码这个东西是需要耐住性子并且需要你投入大量精力的，看过一遍没有印象太正常了，并且看源码的前提是没人打扰，需要一个极度安静的环境。
在回到正题之前，我先来问你一个问题，你知道代理模式和委托模式的区别吗？
回到正题，在真正做解析工作的时候，会首先创建一个委托类BeanDefinitionParserDelegate ，那么先来认识一下这个类。
// 用于解析XML bean定义的有状态委托类。 旨在供主解析器和任何扩展使用
public class BeanDefinitionParserDelegate {
// 此方法也就是委托给 BeanDefinitionParserDelegate 去做的事情
protected BeanDefinitionParserDelegate createDelegate(
XmlReaderContext readerContext, Element root, @Nullable BeanDefinitionParserDelegate parentDelegate) {
BeanDefinitionParserDelegate delegate = new BeanDefinitionParserDelegate(readerContext);
delegate.initDefaults(root, parentDelegate);
return delegate;
}
}
它主要完成的事情在initDefaults 方法中，一起看下这个方法
/*
* 初始化默认的 懒加载，自动注入，依赖检查设置， 初始化方法，销毁方法和合并设置。
* 如果未在本地显式设置默认值，则通过回退到给定父级来支持嵌套的“beans”元素用例。
*/
public void initDefaults(Element root, @Nullable BeanDefinitionParserDelegate parent) {
populateDefaults(this.defaults, (parent != null ? parent.defaults : null), root);
this.readerContext.fireDefaultsRegistered(this.defaults);
}
/**
* in case the defaults are not explicitly set locally.
* 使用默认的 lazy-init,autowire,依赖检查设置,init-method,destroy-method 和 合并设置 属性 填充给定的
* DocumentDefaultsDefinition，如果未在本地显式设置默认值，则支持嵌套的'beans'元素用例，返回parentDefaults
*/
protected void populateDefaults(DocumentDefaultsDefinition defaults, @Nullable DocumentDefaultsDefinition parentDefaults, Element root) {
// default-lazy-init
String lazyInit = root.getAttribute(DEFAULT_LAZY_INIT_ATTRIBUTE);
if (DEFAULT_VALUE.equals(lazyInit)) {
// Potentially inherited from outer <beans> sections, otherwise falling back to false.
lazyInit = (parentDefaults != null ? parentDefaults.getLazyInit() : FALSE_VALUE);
}
defaults.setLazyInit(lazyInit);
// 余下的代码和lazyinit 的逻辑相同，也是解析方法注释中的各种属性。 这里碍于篇幅原因暂不贴出了
...
//
defaults.setSource(this.readerContext.extractSource(root));
}
然后方法一直返回到创建委托的入口也就是 BeanDefinitionParserDelegate parent = this.delegate;，然后是 Spring 留给开发人员的两个接口，用于开发人员自己实现
...
// 在解析Bean定义之前，进行自定义的解析，增强解析过程的可扩展性
preProcessXml(root);
// 委托给 BeanDefinitionParserDelegate,从Document的根元素开始进行BeanDefinition的解析
parseBeanDefinitions(root, this.delegate);
// 在解析Bean定义之后，进行自定义的解析，增加解析过程的可扩展性
postProcessXml(root);
我们再来看一下 parseBeanDefinitions(root, this.delegate); 这个方法是交给刚刚创建的 BeanDefinitionParserDelegate 委托用来解析具体的 lazy-init 等属性的标签的
/**
* 解析文档对象的根目录节点：import, alias, bean
*/
protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
// 加载的Document对象是否使用了Spring默认的XML命名空间（beans命名空间）
if (delegate.isDefaultNamespace(root)) {
// 获取Document对象根元素的所有子节点（bean标签、import标签、alias标签和其他自定义标签context、aop等）
NodeList nl = root.getChildNodes();
for (int i = 0; i < nl.getLength(); i++) {
Node node = nl.item(i);
if (node instanceof Element) {
Element ele = (Element) node;
// bean标签、import标签、alias标签，则使用默认解析规则
if (delegate.isDefaultNamespace(ele)) {
parseDefaultElement(ele, delegate);
}
else {//像context标签、aop标签、tx标签，则使用用户自定义的解析规则解析元素节点
delegate.parseCustomElement(ele);
}
}
}
}
else {
// 如果不是默认的命名空间，则使用用户自定义的解析规则解析元素节点
delegate.parseCustomElement(root);
}
}
上述步骤主要分为三步：
一，先判断是否委托类使用Spring默认的XML命名空间（beans命名空间），在判断如果取出来的节点是bean、import、alias的话就使用默认的解析规则
private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {
// 解析<import>标签
if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) {
importBeanDefinitionResource(ele);
}
// 解析<alias>标签
else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) {
processAliasRegistration(ele);
}
// 解析<bean>标签
else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) {
processBeanDefinition(ele, delegate);
}
// 解析内置<bean>标签
else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) {
// recurse
// 递归调用
doRegisterBeanDefinitions(ele);
}
}
二，如果判断取出来的不是默认节点，则会使用自定义的默认解析规则，context标签，aop标签, tx标签则会默认使用此解析方法
@Nullable
public BeanDefinition parseCustomElement(Element ele) {
// 解析自定义标签
return parseCustomElement(ele, null);
}
@Nullable
public BeanDefinition parseCustomElement(Element ele, @Nullable BeanDefinition containingBd) {
// 获取命名空间URI（就是获取beans标签的xmlns:aop或者xmlns:context属性的值）
String namespaceUri = getNamespaceURI(ele);
if (namespaceUri == null) {
return null;
}
// 根据不同的命名空间URI,去匹配不同的NamespaceHandler(一个命名空间对应一个NamespaceHandler)
// 此处会调用DefaultNamespaceHandlerResolver类的resolve方法
NamespaceHandler handler = this.readerContext.getNamespaceHandlerResolver().resolve(namespaceUri);
if (handler == null) {
error("Unable to locate Spring NamespaceHandler for XML schema namespace [" + namespaceUri + "]", ele);
return null;
}
// 调用匹配到的NamespaceHandler的解析方法
return handler.parse(ele, new ParserContext(this.readerContext, this, containingBd));
}
三，如果不是使用 beans 的命名空间，也会使用自定义的解析方法进行解析
然后方法解析完成，一直返回到 AbstractApplicationContext 中的 刷新 bean Factory 的方法
protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
// 主要是通过该方法完成IoC容器的刷新
// ClassPathXmlApplicationContext.refreshBeanFactory 调用的是 AbstractRefreshApplicationContext
// AnnotationConfigApplicationContext.refreshBeanFactory调用的是GenericApplicationContext
refreshBeanFactory();
ConfigurableListableBeanFactory beanFactory = getBeanFactory();
if (logger.isDebugEnabled()) {
logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory);
}
return beanFactory;
}
这样取出的 Bean 对象就可以进行使用了。
下一篇文章来 解析一下第三个步骤：对IoC容器进行一些预处理
推荐阅读(点击即可跳转阅读)
2. 面试题内容聚合
3. 设计模式内容聚合
4. Mybatis内容聚合
5. 多线程内容聚合