6 IoC容器的初始化过程

简单来说，IoC容器的初始化是由前面介绍的refresh()方法来启动的，这个方法标志着IoC容器的正式启动。具体来说，这个启动包括BeanDefinition的Resouce定位、载入和注册三个基本过程。如果我们了解如何编程式地使用IoC容器，就可以清楚地看到Resource定位和载入过程的接口调用。在下面的内容里，我们将会详细分析这三个过程的实现。
在分析之前，要提醒读者注意的是，Spring把这三个过程分开，井使用不同的模块来完成，如使用相应的ResourceLoader、BeanDefinitionReader等模块，通过这样的设计方式，可以让用户更加灵活地对这三个过程进行剪裁或扩展，定义出最适合自己的IoC容器的初始化过程。

1. 第一个过程是Resource定位过程。这个Resource定位指的是BeanDefinition的资源定位，它由ResourceLoader通过统一的Resource接口来完成，这个Resource对各种形式的BeanDefinition的使用都提供了统一接口。对千这些BeanDefinition的存在形式，相信大家都不会感到陌生。比如，在文件系统中的Bean定义信息可以使用FileSystemResource来进行抽象，在类路径中的Bean定义信息可以使用前面提到的ClassPathResource来使用，等等。这个定位过程类似于容器寻找数据的过程，就像用水桶装水先要把水找到一样。
2. 第二个过程是BeanDefinition的载入。这个载入过程是把用户定义好的Bean表示成IoC容器内部的数据结构，而这个容器内部的数据结构就是BeanDefinition。下面介绍这个数据结构的详细定义。具体来说，这个BeanDefinition实际上就是POJO对象在IoC容器中的抽象，通过这个BeanDefinition定义的数据结构，使IoC容器能够方便地对POJO对象也就是Bean进行管理。在下面的章节中，我们会对这个载入的过程进行详细的分析，使大家对整个过程有比较清楚的了解。
3. 第三个过程是向IoC容器注册这些BeanDefinition的过程。这个过程是通过调用BeanDefinitionRegistry接口的实现来完成的。这个注册过程把载人过程中解析得Be到an的Definition向IoC容器进行注册。通过分析，我们可以看到，在IoC容器内部将BeanDefinition注入到一个HashMap中去，IoC容器就是通过这个HashMap来持有这些BeanDefinition数据的。
   值得注意的是，这里谈的是IoC容器初始化过程，在这个过程中，一般不包含Bean依赖注入的实现。在Spring IoC的设计中，Bean定义的载入和依赖注人是两个独立的过程。依赖注入一般发生在应用第一次通过getBean向容器索取Bean的时候。但有一个例外值得注意，在使用IoC容器时有一个预实例化的配置，通过这个预实例化的配置（具体来说，可以通过为Bean定义信息中的lazyinit属性），用户可以对容器初始化过程作一个微小的控制，从而改变这个被设置了lazyinit属性的Bean的依赖注人过程。举例来说，如果我们对某个Bean设置了Iazyinit属性，那么这个Bean的依赖注入在IoC容器初始化时就预先完成了，而不需要等到整个初始化完成以后，第一次使用getBean时才会触发。

了解了IoC容器进行初始化的大致轮廓之后，下面我们详细地介绍在loC容器的初始化过程中，BeanDefinition的资源定位、载入和解析过程是怎么实现的。

BeanDefinition的Resource定位

以编程的方式使用DefaultListableBeanFactory时，首先定义一个Resource来定位容器使用的BeanDefinition。这时使用的是ClassPathResource,这意味着Spring会在类路径中去寻找以文件形式存在的BeanDefinition信息。
ClassPathResource res= newClassPathResource(“beans,xml”);
这里定义的Resource并不能由DefaultListableBeanFactory直接使用，Spring通过BeanDefinitionReader来对这些信息进行处理。在这里，我们也可以看到使用Application-Context相对千直接使用DefaultListableBeanFactory的好处。因为在ApplicationContext中，Spring已经为我们提供了一系列加载不同Resource的读取器的实现，而DefaultListableBeanFactory只是一个纯粹的loC容器，需要为它配置特定的读取器才能完成这些功能。当然，有弊就有利，使用DefaultListableBeanFactory这种更底层的容器，能提高定制IoC容器的灵活性。
回到我们经常使用的ApplicationContext上来，例如FileSystemXmlApplicationContext、ClassPathXmlApplicationContext以及XmlWebApplicationContext等。简单地从这些类的名字上分析，可以渚楚地着到它们可以提供哪些不同的Resource读入功能，比如FilesystemXmlApplicationContext可以从文件系统载入Resource,ClassPathXmlApplicationContext可以从ClassPath载人Resource, XmlWebApplicationContext可以在Web容器中载入Resource,等等。
下面以FileSystemXmlApplicationContext为例，通过分析这个ApplicationContext的实现来看看它是怎样完成这个Resource定位过程的。作为辅助，我们可以在图中看到相应的ApplicationContext继承体系。

从图中可以看到，这个FileSystemXmlApplicationContext已经通过继承AbstractApplicationContex具备了从ResourceLoader读入以Resource定义的BeanDefinition的能力，因为AbstractAppIicationContext的基类是DefaultResourceLoader。下面让我们看看FileSystemXmlApplicationContext的具体实现，如代码清单所示。

public class FileSystemXmlApplicationContext extends AbstractXmlApplicationContext {

    /**
     * Create a new FileSystemXmlApplicationContext for bean-style configuration.
     * 为bean-style configuration创建一个新的FileSystemXmlApplicationContext。
     */
    public FileSystemXmlApplicationContext() {
    }

    /**
     * Create a new FileSystemXmlApplicationContext for bean-style configuration.
     * 为bean-style configuration创建一个新的FileSystemXmlApplicationContext。
     */
    public FileSystemXmlApplicationContext(ApplicationContext parent) {
        super(parent);
    }

    /**
     * Create a new FileSystemXmlApplicationContext, loading the definitions
     * from the given XML file and automatically refreshing the context.
     * 创建一个新的FileSystemXmlApplicationContext，从给定的XML文件加载定义并自动更新上下文
     */
    public FileSystemXmlApplicationContext(String configLocation) throws BeansException {
        this(new String[] {configLocation}, true, null);
    }

    /**
     * Create a new FileSystemXmlApplicationContext, loading the definitions
     * from the given XML files and automatically refreshing the context.
     * 创建一个新的FileSystemXmlApplicationContext，从给定的XML文件加载定义并自动更新上下文
     */
    public FileSystemXmlApplicationContext(String... configLocations) throws BeansException {
        this(configLocations, true, null);
    }

    /**
     * Create a new FileSystemXmlApplicationContext with the given parent,
     * loading the definitions from the given XML files and automatically
     * refreshing the context.
     * 用给定的parent ApplicationContext创建一个新的FileSystemXmlApplicationContext，从给定的XML文件加载定义并自动刷新上下文。
     */
    public FileSystemXmlApplicationContext(String[] configLocations, ApplicationContext parent) throws BeansException {
        this(configLocations, true, parent);
    }

    /**
     * Create a new FileSystemXmlApplicationContext, loading the definitions
     * from the given XML files.
     * 创建一个新的FileSystemXmlApplicationContext，从给定的XML文件中加载定义。
     */
    public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh) throws BeansException {
        this(configLocations, refresh, null);
    }

    /**
     * Create a new FileSystemXmlApplicationContext with the given parent,
     * loading the definitions from the given XML files.
     * 创建一个新的FileSystemXmlApplicationContext，从给定的XML文件中加载定义。
     */
    public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
            throws BeansException {

        super(parent);
        setConfigLocations(configLocations);
        if (refresh) {
            refresh();
        }
    }


    /**
     * Resolve resource paths as file system paths.
     * 将资源路径解析为文件系统路径。
     * <p>Note: Even if a given path starts with a slash, it will get
     * interpreted as relative to the current VM working directory.
     * This is consistent with the semantics in a Servlet container.
     * 即使给定的路径以斜杠开始，它也会被解释为相对于当前VM工作目录。这与Servlet容器中的语义是一致的。
     */
    @Override
    protected Resource getResourceByPath(String path) {
        if (path != null && path.startsWith("/")) {
            path = path.substring(1);
        }
        return new FileSystemResource(path);
    }

}

在FileSystemApplicationContext中，我们可以看到在构造函数中，实现了对configuration进行处理的功能，让所有配置在文件系统中的，以XML文件方式存在的BeanDefnition都能够得到有效的处理，比如，实现了getResourceByPath方法，这个方法是一个模板方法，是为读取Resource服务的。对于IoC容器功能的实现，这里没有涉及，因为它继承了AbstractXmlApplicationContext，关于IoC容器功能相关的实现，都是在AbstractXmlApplicationContext中完成的，但是在构造函数中通过refresh来启动IoC容器的初始化，这个refresh方法非常重要，也是我们以后分析容器初始化过程实现的一个重要入口。

注意FileSystemApplicationContext是一个支持XML定义Beanpefinition的ApplicationContext，并且可以指定以文件形式的BeanDefinition的读入，这些文件可以使用文件路径和URL定义来表示。在测试环境和独立应用环境中，这个ApplicationContext是非常有用的。

这个对BeanDefinition资源定位的过程，最初是由refresh来触发的，这个refresh的调用是在FileSysternXmlBeanFactory的构造函数中启动的，这个FileSystemXm1ApplicationContext在什么地方定义了BeanDefinition的读入器BeanDefinitionReader,从而完成BeanDefinition倌息的读入呢？在前面分析过，在IoC容器的初始化过程中，BeanDefinition资源的定位、读入和注册过程是分开进行的，这也是解耦的一个体现。关于这个读入器的配置，可以到FileSystemXmlApplicationContext的基类AbstractRefreshableApplicationContext中看看它是怎样实现的。