Spring源码阅读之IoC容器初始化1 -- Resource定位
注1：Spring源码基于Spring3.1版本
注2：参考《Spring技术内幕》第二版
1、Spring IoC容器初始化
Spring IoC容器的初始化包括BeanDefinition的Resource定位、载入和注册三个基本过程。在具体分析这三个过程之前，需要注意的是Spring把这三个过程分开，并使用不同的模块来完成，这样使Spring IoC容器更加灵活。
Resource定位
这里Resource指的是BeanDefinition的资源定位，它由ResourceLoader通过统一的Resource接口来完成，对各种形式的BeanDefinition都提供了统一的接口。比如文件系统中的Bean定义信息可以使用FileSystemResource来抽象；类路径中的Bean定义信息可以使用ClassPathResource来抽象，等等。
这个Resource定位过程其实就是IoC容器寻找Bean定义数据的过程。
关于Spring中Resource的更多介绍，这里有一篇博客：http://blog.csdn.net/zhangyihui1986/article/details/8793626
BeanDefinition的载入
这个载入过程就是把定义好的Bean表示成容器内部的数据结构BeanDefinition。这个BeanDefinition实际上就是POJO对象在IoC容器中的抽象，通过这个BeanDefinition定义的数据结构，使IoC容器能够方便地对POJO对象也就是Bean进行管理。
向IoC容器注册BeanDefinition
这个过程是通过调用BeanDefinitionRegistry接口的实现来完成的，该注册过程把载入过程中解析得到的BeanDefinition向IoC容器进行注册。其实在IoC容器内部就是将BeanDefinition注入到一个HashMap中，IoC容器就是通过这个HashMap来持有这些BeanDefinition数据的。
额外说明
需要注意的是，这里说的IoC容器的初始化过程一般不包括依赖注入的实现。在Spring的设计中，Bean定义的载入和依赖注入是两个独立的过程，依赖注入一般发生在应用第一次通过getBean向容器索取Bean实例的时候。有一个例外就是当我们在Bean定义中指定的lazyinit属性（预实例化配置），那么这个Bean的依赖注入在IoC容器的初始化时就完成了，不需要等到初始化完成之后，第一次获取该Bean时才触发。
下面从源码分析一下IoC容器初始化过程中的第一个步骤 -- Resource定位。
2、Resource定位
源码分析从FileSystemXmlApplicationContext类开始，因为《Spring技术内幕》中就是以该类为为起点来讲述IoC容器的初始化，这样可以引用书中的一些理论及代码解释。
如果我们以编程的方式使用DefaultListableBeanFactory时，会使用类似下面的方式：
DefaultListableBeanFactory beanFactory = new DefaultListableBeanFactory();
Resource resource = new FileSystemResource("xxx.xml");
XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(beanFactory);
reader.loadBeanDefinitions(resource);
我们需要创建一个FileSystemResource（或其它Resource如ClassPathResource）来定位Resource，这里的Resource并不能为DefaultListableBeanFactory直接使用，而是通过BeanDefinitionReader（上例中使用实现类XmlBeanDefinitionReader）对这些信息进行处理。
而使用ApplicationContext相对于直接使用DefaultListableBeanFactory带来的一点好处就是ApplicationContext已经提供了一系列加载不同的Resource的功能，因为Spring中的各种ApplicationContext都实现了ResourceLoader接口（基类AbstractApplicationContext继承了DefaultResourceLoader，而DefaultResourceLoader是ResourceLoader接口的默认实现类）。
FileSystemXmlApplicationContext的继承体系
先分别从Spring源码角度和UML类图角度看一下FileSystemXmlApplicationContext的继承体系：
从继承体系可以看出，FileSystemXmlApplicationContext已经通过继承AbstractApplicationContext具备了ResourceLoader读入以Resource形式定义的BeanDefinition的能力，因为AbstractApplicationContext的基类是DefaultResourceLoader，而DefaultResourceLoader是ResourceLoader的默认实现。
FileSystemXmlApplicationContext源码实现：
package org.springframework.context.support;
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.core.io.FileSystemResource;
import org.springframework.core.io.Resource;
public class FileSystemXmlApplicationContext extends AbstractXmlApplicationContext {
public FileSystemXmlApplicationContext() {}
public FileSystemXmlApplicationContext(ApplicationContext parent) {
super(parent);
}
// configLocation是BeanDefinition所在的文件路径
public FileSystemXmlApplicationContext(String configLocation) throws BeansException {
this(new String[] {configLocation}, true, null);
}
// 可以指定多个BeanDefinition资源路径
public FileSystemXmlApplicationContext(String... configLocations) throws BeansException {
this(configLocations, true, null);
}
// 可以指定多个BeanDefinition资源路径, 同时指定自己的双亲容器
public FileSystemXmlApplicationContext(String[] configLocations, ApplicationContext parent) throws BeansException {
this(configLocations, true, parent);
}
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh) throws BeansException {
this(configLocations, refresh, null);
}
// 调用父类AbstractRefreshableConfigApplicationContext的方法，设置BeanDefinition定义的资源文件，完成IoC容器Bean定义资源的定位
// 调用父类AbstractApplicationContext的refresh()方法, 这个方法启动了BeanDefinition的载入过程, 是Ioc容器载入Bean定义的入口
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
throws BeansException {
super(parent);
setConfigLocations(configLocations);
if (refresh) {
refresh();
}
}
// 覆盖父类DefaultResourceLoader的方法，通过FileSystemResource得到在文件系统中定位的BeanDefinition
// 该getResourceByPath方法在BeanDefinitionReader的loadBeanDefinition中被调用, loadBeanDefinition采用模版模式, 具体定位由子类完成
protected Resource getResourceByPath(String path) {
if (path != null && path.startsWith("/")) {
path = path.substring(1);
}
return new FileSystemResource(path);
}
}
可以看到，在构造函数中实现了对configuration进行处理的操作，然后调用refresh方法启动IoC容器的初始化，这个refresh方法定义在AbstractApplicationContext类中，是一个非常重要的方法，是分析容器初始化过程的重要入口。
getResourceByPath的调用关系
下面我们来看一下refresh方法到getResourceByPath方法的调用关系图：
由上图可以清楚地看到整个BeanDefinition资源定位的过程，最初是由refresh方法触发，而refresh的调用是在FileSystemXmlApplicationContext的构造函数中启动。如果跟着源码去refresh方法中查看，就会发现refresh方法好像是一个总开关，在方法内部调用了很多其它的方法来完成IoC的初始化，其中就有obtainFreshBeanFactory方法，而obtainFreshBeanFactory又调用了AbstractRefreshableApplicationContext类中的refreshBeanFactory方法，正是由这个方法调用loadBeanDefinitions来加载BeanDefinition，下面来看一下refreshBeanFactory方法的实现。
Resource的定位源码
由上面分析可知，AbstractApplicationContext类的refresh方法是IoC容器初始化的入口，refresh方法调用了很多其它的方法，其实中就有obtainFreshBeanFactory方法，而obtainFreshBeanFactory又调用了AbstractRefreshableApplicationContext类中的refreshBeanFactory方法，我们从refreshBeanFactory方法开始分析。
AbstractRefreshableApplicationContext类中的refreshBeanFactory方法：
protected final void refreshBeanFactory() throws BeansException {
// 如果已经建立了BeanFactory，则销毁并关闭该BeanFactory
if (hasBeanFactory()) {
destroyBeans();
closeBeanFactory();
}
try {
// 创建并持有DefaultListableBeanFactory实例，同时调用loadBeanDefinitions方法来载入BeanDefinition信息
DefaultListableBeanFactory beanFactory = createBeanFactory();
beanFactory.setSerializationId(getId());
customizeBeanFactory(beanFactory);
loadBeanDefinitions(beanFactory);
synchronized (this.beanFactoryMonitor) {
this.beanFactory = beanFactory;
}
} catch (IOException ex) {
throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex);
}
}
// 创建DefaultListableBeanFactory实例，getInternalParentBeanFactory方法的实现可以参看AbstractApplicationContext类源码，它会根据已有的双亲IoC容器信息来生成DefaultListableBeanFactory的双亲容器
protected DefaultListableBeanFactory createBeanFactory() {
return new DefaultListableBeanFactory(getInternalParentBeanFactory());
}
在这个方法中，通过调用createBeanFactory方法构建并持有一个IoC容器供ApplicationContext使用，这个IoC容器就是前面提到的DefaultListableBeanFactory，同时它启动了loadBeanDefinitions来载入BeanDefinition，这个过程与以编程式的方式来使用IoC容器（DefaultListableBeanFactory 结合 XmlBeanDefinitionReader）的过程非常相似。
接着进入到loadBeanDefinitions方法，这个方法在AbstractApplicationContext中是个抽象方法，具体的实现在AbstractXmlApplicationContext类中。
AbstractXmlApplicationContext的loadBeanDefinitions方法：
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
// 使用刚创建的BeanFactory创建一个新的XmlBeanDefinitionReader.
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
// 配置XmlBeanDefinitionReader.
beanDefinitionReader.setEnvironment(this.getEnvironment());
beanDefinitionReader.setResourceLoader(this);
beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
// 初始化XmlBeanDefinitionReader, 然后加载BeanDefinition
initBeanDefinitionReader(beanDefinitionReader);
loadBeanDefinitions(beanDefinitionReader);
}
// 实际加载BeanDefinition
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
Resource[] configResources = getConfigResources();
if (configResources != null) {
reader.loadBeanDefinitions(configResources);
}
String[] configLocations = getConfigLocations();
if (configLocations != null) {
reader.loadBeanDefinitions(configLocations);
}
}
从上面一段代码可以得知，loadBeanDefinitions方法首先创建了一个XmlBeanDefinitionReader实例，在完成配置与初始化之后执行了该XmlBeanDefinitionReader的loadBeanDefinitions方法，这里是真正载入BeanDefinition的地方，自此程序执行流程进入到XmlBeanDefinitionReader中。
跟着去看一下如何完成的。
XmlBeanDefinitionReader的loadBeanDefinitions方法：
public int loadBeanDefinitions(String... locations) throws BeanDefinitionStoreException {
int counter = 0;
for (String location : locations) {
counter += loadBeanDefinitions(location);
}
return counter;
}
public int loadBeanDefinitions(String location) throws BeanDefinitionStoreException {
return loadBeanDefinitions(location, null);
}
public int loadBeanDefinitions(String location, Set<Resource> actualResources) throws BeanDefinitionStoreException {
// 取得ResourceLoader, 这里使用的是DefaultResourceLoader, AbstractApplicationContext继承了DefaultResourceLoader
ResourceLoader resourceLoader = getResourceLoader();
if (resourceLoader == null) {
throw new BeanDefinitionStoreException("Cannot import bean definitions from location [" + location + "]: no ResourceLoader available");
}
// 对Resource的路径模式进行解析, 得到需要的Resource集合, 这些Resource集合指向我们定义的BeanDefinition信息, 可以是多个文件
if (resourceLoader instanceof ResourcePatternResolver) {
// 调用DefaultResourceLoader的getResources方法完成具体的Resource定位
try {
Resource[] resources = ((ResourcePatternResolver) resourceLoader).getResources(location);
int loadCount = loadBeanDefinitions(resources);
if (actualResources != null) {
for (Resource resource : resources) {
actualResources.add(resource);
}
}
return loadCount;
} catch (IOException ex) {
throw new BeanDefinitionStoreException("Could not resolve bean definition resource pattern [" + location + "]", ex);
}
} else {
// 调用DefaultResourceLoader的getResource方法完成具体的Resource定位.
Resource resource = resourceLoader.getResource(location);
int loadCount = loadBeanDefinitions(resource);
if (actualResources != null) {
actualResources.add(resource);
}
return loadCount;
}
}
由上面代码可以看出，多个资源定位符location会被逐一定位加载；另外，对于FileSystemXmlApplicationContext会进入loadBeanDefinitions方法中的else流程，这里会直接调用ResourceLoader的getResource方法，也就是其默认实现类DefaultResourceLoader的getResource方法。
DefaultResourceLoader的getResource方法：
// 具体取得Resource的过程, 定义在DefaultResourceLoader中
public Resource getResource(String location) {
// 处理带有classpath标识的Resource
if (location.startsWith(CLASSPATH_URL_PREFIX)) {
return new ClassPathResource(location.substring(CLASSPATH_URL_PREFIX.length()), getClassLoader());
} else {
try {
// 作为URL定位的Resource处理
URL url = new URL(location);
return new UrlResource(url);
} catch (MalformedURLException ex) {
// 不是URL标识的location, 将Resource定位任务交给getResourceByPath,
// 这是个protected方法, 默认实现为得到一个ClassPathContextResource, 常用来被子类重写.
return getResourceByPath(location);
}
}
}
在前面的源码分析中，getResourceByPath方法被DefaultResourceLoader的子类FileSystemXmlApplicationContext实现，这个方法返回一个FileSystemResource对象，通过该FileSystemResource对象，Spring便可以完成BeanDefinition定位。
分析到这里IoC容器FileSystemXmlApplicationContext的Resource的定位已经一目了然了，如果是其它类型的ApplicationContext，那么会相应生成其它各类的Resource，比如ClassPathResource、ServletContextResource等。