Spring IoC容器初始化 — Resource定位源码分析
在Spring IoC容器的设计中，有两个主要的容器系列。一个是实现了BeanFactory接口的简单容器系列，这系列容器只实现了容器基本的功能；另一个是ApplicationContext应用上下文，它在简单容器的基础上增加了许多面向框架的特性，同时对应用环境做了许多适配。
IoC容器的初始化过程
Spring IoC容器的初始化过程分为三个阶段：Resource定位、BeanDefinition的载入和向IoC容器注册BeanDefinition。Spring把这三个阶段分离，并使用不同的模块来完成，这样可以让用户更加灵活的对这三个阶段进行扩展。
Resource定位指的是BeanDefinition的资源定位，它由ResourceLoader通过统一的Resource接口来完成，Resource对各种形式的BeanDefinition的使用都提供了统一的接口。BeanDefinition的载入是把用户定义好的Bean表示成IoC容器内部的数据结构，而这个容器内部的数据结构就是BeanDefinition，BeanDefinition实际上就是POJO对象在IoC容器中的抽象。通过BeanDefinition，IoC容器可以方便的对POJO对象进行管理。- 向
IoC容器注册BeanDefinition是通过调用BeanDefinitionRegistry接口的实现来完成的，这个注册过程是把载入的BeanDefinition向IoC容器进行注册。实际上，在IoC容器内部维护着一个HashMap，而这个注册过程其实就将BeanDefinition添加至这个HashMap。
我们可以自己定义Resource、BeanFactory和BeanDefinitionReader来初始化一个容器。如下代码片段使用了DefaultListableBeanFactory作为实际使用的IoC容器。同时，创建IoC配置文件（dispatcher-servlet.xml）的抽象资源，这个抽象资源包含了BeanDefinition的定义信息。最后，还需要创建一个载入BeanDefinition的读取器，此处使用XmlBeanDefinitionReader，通过一个回调配置给BeanFactory。
ClassPathResource res = new ClassPathResource("dispatcher-servlet.xml");
DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
reader.loadBeanDefinitions(res);
我们也可以通过ApplicationContext创建一个IoC容器。在Spring中，系统已经提供许多定义好的容器实现，而不需要自己组装。如下代码片段以FileSystemXmlApplicationContext为例创建了一个IoC容器。
FileSystemXmlApplicationContext context =
new FileSystemXmlApplicationContext("classpath:dispatcher-servlet.xml");
无论使用哪种方式初始化IoC容器，都会经历上述三个阶段。本篇文章将结合Spring 4.0.2源码，并以FileSystemXmlApplicationContext为例对IoC容器初始化的第一阶段，也就是Resource定位阶段进行分析。
BeanDefinition的Resource定位
下图展示了FileSystemXmlApplicationContext的继承体系，FileSystemXmlApplicationContext继承自AbstractApplicationContext，而AbstractApplicationContext又继承自DefaultResourceLoader，DefaultResourceLoader实现了ResourceLoader接口。因此FileSystemXmlApplicationContext具备读取定义了BeanDefinition的Resource的能力。
我们的分析入口是new FileSystemXmlApplicationContext("classpath:dispatcher-servlet.xml");，这句代码调用了FileSystemXmlApplicationContext的构造方法。FileSystemXmlApplicationContext的构造方法源码如下（只提取与本次分析关联的代码）。
public FileSystemXmlApplicationContext(String configLocation) throws BeansException {
this(new String[]{configLocation}, true, (ApplicationContext)null);
}
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh,
ApplicationContext parent) throws BeansException {
super(parent);
this.setConfigLocations(configLocations);
if(refresh) {
this.refresh();
}
}
在创建FileSystemXmlApplicationContext时，我们仅传入了包含BeanDefinition的配置文件路径（classpath:dispatcher-servlet.xml），由此调用FileSystemXmlApplicationContext(String configLocation)构造方法。接着，FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)构造方法被间接调用，在该构造方法内部，refresh方法完成了整个IoC容器的初始化。因此，refresh方法是我们分析的下一个入口。
refresh方法的具体实现定义在FileSystemXmlApplicationContext的父类AbstractApplicationContext中，对应的源码如下。
public void refresh() throws BeansException, IllegalStateException {
Object var1 = this.startupShutdownMonitor;
synchronized(this.startupShutdownMonitor) {
this.prepareRefresh();
ConfigurableListableBeanFactory beanFactory = this.obtainFreshBeanFactory();
this.prepareBeanFactory(beanFactory);
try {
this.postProcessBeanFactory(beanFactory);
this.invokeBeanFactoryPostProcessors(beanFactory);
this.registerBeanPostProcessors(beanFactory);
this.initMessageSource();
this.initApplicationEventMulticaster();
this.onRefresh();
this.registerListeners();
this.finishBeanFactoryInitialization(beanFactory);
this.finishRefresh();
} catch (BeansException var5) {
this.destroyBeans();
this.cancelRefresh(var5);
throw var5;
}
}
}
在refresh方法中，通过obtainFreshBeanFactory方法，ConfigurableListableBeanFactory类型的BeanFactory被创建。我们接着进入obtainFreshBeanFactory方法，obtainFreshBeanFactory方法也定义在AbstractApplicationContext中。
protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
this.refreshBeanFactory();
ConfigurableListableBeanFactory beanFactory = this.getBeanFactory();
if(this.logger.isDebugEnabled()) {
this.logger.debug("Bean factory for " + this.getDisplayName() + ": " + beanFactory);
}
return beanFactory;
}
protected abstract void refreshBeanFactory() throws BeansException, IllegalStateException;
我们重点关注refreshBeanFactory方法的实现。在AbstractApplicationContext中，refreshBeanFactory方法仅仅是个声明，具体的实现委托给了子类完成。此处，refreshBeanFactory方法的具体实现定义在了AbstractRefreshableApplicationContext，AbstractRefreshableApplicationContext正是继承自AbstractApplicationContext，这点我们可以从上文的继承体系图可以得知。refreshBeanFactory方法在AbstractRefreshableApplicationContext中的定义如下。
protected final void refreshBeanFactory() throws BeansException {
if(this.hasBeanFactory()) {
this.destroyBeans();
this.closeBeanFactory();
}
try {
DefaultListableBeanFactory ex = this.createBeanFactory();
ex.setSerializationId(this.getId());
this.customizeBeanFactory(ex);
this.loadBeanDefinitions(ex);
Object var2 = this.beanFactoryMonitor;
synchronized(this.beanFactoryMonitor) {
this.beanFactory = ex;
}
} catch (IOException var5) {
throw new ApplicationContextException("I/O error parsing bean definition source for " + this.getDisplayName(), var5);
}
}
protected abstract void loadBeanDefinitions(DefaultListableBeanFactory var1) throws BeansException, IOException;
refreshBeanFactory方法首先会判断是否已经建立的BeanFactory，如果已经建立，那么需要销毁并关闭该BeanFactory。接着，refreshBeanFactory方法通过createBeanFactory方法创建了一个IoC容器供ApplicationContext使用，且这个IoC容器的实际类型为DefaultListableBeanFactory。同时，refreshBeanFactory方法将这个IoC容器作为参数，调用loadBeanDefinitions载入了BeanDefinition（本文暂不分析载入过程的具体操作）。
loadBeanDefinitions方法也仅仅在AbstractRefreshableApplicationContext中声明，具体的实现定义在AbstractXmlApplicationContext中，从继承体系图我们可以得知AbstractXmlApplicationContext正是AbstractRefreshableApplicationContext的子类。loadBeanDefinitions方法对应的源码如下。
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);
beanDefinitionReader.setEnvironment(this.getEnvironment());
beanDefinitionReader.setResourceLoader(this);
beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));
this.initBeanDefinitionReader(beanDefinitionReader);
this.loadBeanDefinitions(beanDefinitionReader);
}
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
Resource[] configResources = this.getConfigResources();
if(configResources != null) {
reader.loadBeanDefinitions(configResources);
}
String[] configLocations = this.getConfigLocations();
if(configLocations != null) {
reader.loadBeanDefinitions(configLocations);
}
}
在loadBeanDefinitions(DefaultListableBeanFactory beanFactory)中，定义了BeanDefinition的读入器beanDefinitionReader。Spring把定位、读入和注册的过程解耦，这正是体现之处之一。接着beanDefinitionReader作为参数，调用loadBeanDefinitions(XmlBeanDefinitionReader reader)方法，如果configResources为空，那么reader就会根据configLocations调用reader的loadBeanDefinitions去加载相应的Resource。在AbstractBeanDefinitionReader和XmlBeanDefinitionReader中个自定义了不同的loadBeanDefinitions方法，与我们本次分析相关的代码定义在AbstractBeanDefinitionReader中，如下所示。
public int loadBeanDefinitions(String... locations) throws BeanDefinitionStoreException {
Assert.notNull(locations, "Location array must not be null");
int counter = 0;
String[] var3 = locations;
int var4 = locations.length;
for(int var5 = 0; var5 < var4; ++var5) {
String location = var3[var5];
counter += this.loadBeanDefinitions(location);
}
return counter;
}
public int loadBeanDefinitions(String location) throws BeanDefinitionStoreException {
return this.loadBeanDefinitions(location, (Set)null);
}
public int loadBeanDefinitions(String location, Set<Resource> actualResources) throws BeanDefinitionStoreException {
ResourceLoader resourceLoader = this.getResourceLoader();
if(resourceLoader == null) {
throw new BeanDefinitionStoreException("Cannot import bean definitions from location [" + location + "]: no ResourceLoader available");
} else {
int loadCount;
if(!(resourceLoader instanceof ResourcePatternResolver)) {
Resource var11 = resourceLoader.getResource(location);
loadCount = this.loadBeanDefinitions((Resource)var11);
if(actualResources != null) {
actualResources.add(var11);
}
if(this.logger.isDebugEnabled()) {
this.logger.debug("Loaded " + loadCount + " bean definitions from location [" + location + "]");
}
return loadCount;
} else {
try {
Resource[] resource =
((ResourcePatternResolver)resourceLoader).getResources(location);
loadCount = this.loadBeanDefinitions(resource);
if(actualResources != null) {
Resource[] var6 = resource;
int var7 = resource.length;
for(int var8 = 0; var8 < var7; ++var8) {
Resource resource1 = var6[var8];
actualResources.add(resource1);
}
}
if(this.logger.isDebugEnabled()) {
this.logger.debug("Loaded " + loadCount + " bean definitions from location pattern [" + location + "]");
}
return loadCount;
} catch (IOException var10) {
throw new BeanDefinitionStoreException("Could not resolve bean definition resource pattern [" + location + "]", var10);
}
}
}
}
在loadBeanDefinitions(String location, Set<Resource> actualResources)方法中，我们可以看到，Resource的定位工作交给了ResourceLoader来完成。对于取得Resource的具体过程，我们可以看看DefaultResourceLoader是怎样完成的，对应源码如下。
public Resource getResource(String location) {
Assert.notNull(location, "Location must not be null");
if(location.startsWith("classpath:")) {
return new ClassPathResource(location.substring("classpath:".length()),
this.getClassLoader());
} else {
try {
URL ex = new URL(location);
return new UrlResource(ex);
} catch (MalformedURLException var3) {
return this.getResourceByPath(location);
}
}
}
由于我们传入的location为classpath:dispatcher-servlet.xml，因此getResource方法会生成一个ClassPathResource并返回，如果我们传入的是一个文件路径，那么会调用getResourceByPath方法，getResourceByPath方法定义在FileSystemXmlApplicationContext中，对应的源码如下。
protected Resource getResourceByPath(String path) {
if(path != null && path.startsWith("/")) {
path = path.substring(1);
}
return new FileSystemResource(path);
}
到此，我们完成了IoC容器在初始化过程中的Resource定位过程的流程分析，这为接下来进行BeanDefinition数据的载入和解析创造了条件。
后续我会对BeanDefinition的载入和解析过程结合源码进行分析，欢迎关注。若本文存在分析不妥之处，建议发送邮件至tinylcy (at) gmail.com交流，直接在页面评论亦可。