前言
本文基于《Spring源码深度解析》学习， 《Spring源码深度解析》讲解的Spring版本低于Spring3.1，当前阅读的版本为Spring5.x，所以在文章内容上会有所不同。
这篇文章基于有一定Spring 基础的人进行讲解，所以有些问题并不做详细的实现， 如有分析不合理或是错误的地方请指教指正，不胜感激。
一、在非ApplicationContext下使用
在《Spring源码深度解析》中有这样一个实例：
public class BeanFactoryTest {
@test
public void testSimpleLoad() {
BeanFactory bf = new XmBeanFactory(new ClassPathResource("beanFactoryTest.xml");
MyTestBean bean = (MyTestBean) bf.getBean("myTestBean");
assertEquals("testStr", bean.getTestStr());
}
}
当然在这里会有一个Spring的配置文件 beanFactoryTest.xml， 当使用xml文件的时候，会发现文件头有一些<?xml ……> <beans></beans>
这样的标签， 建议学习一下DOM，DOM2， DOM3结构, 以便更加清晰的了解xml文件头中的内容的真正意义。
这里的配置文件只写一个相关的bean
<bean id="myTestBean" class="bean.MyTestBean"></bean>这段代码的作用就是以下几点：
- 读取配置文件。
- 在Spring的配置中找到bean，并实例化。
- 使用断言判断实例的属性。
@deprecated as of Spring 3.1 in favor of {@link DefaultListableBeanFactory} and {@link XmlBeanDefinitionReader}
这是该类在当前版本的部分注释，在Spring3.1以后这个类被弃用了，Spring官方不建议使用这个类。建议使用以上这两个类。XmlBeanDefinitionReader本就是以前定义在这个类中的一个final的实例，而DefaultListableBeanFactory则是该类的超类。加载配置文件可以这样使用：
Resource resource = new ClassPathResource("beanFactoryTest.xml");
BeanFactory beanFactory = new DefaultListableBeanFactory();
BeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader((BeanDefinitionRegistry) beanFactory);
beanDefinitionReader.loadBeanDefinitions(resource);
MyTestBean bean = (MyTestBean) bf.getBean("myTestBean");
assertEquals("testStr", bean.getTestStr());
这个过程和上面的过程实际上的实现只用一点不同、前者是在创建时就直接实例化了bean， 后者则是在加载的时候才实例化bean：
- 读取配置文件。
- 创建BeanFactory。
- 创建BeanDefinitionReader。
- 加载resource资源。
- 获取bean实例（实例化bean）。
- 使用断言判断实例的属性。
事实上在实际的使用中，绝大多数时候都会通过以下这种ApplicationContext的方式来加载Spring的配置文件并进行解析， 以后会写到这里的实现：
ApplicationContext sc = new ClassPathXmlApplicationContext("applicationContext.xml");
二、加载并解析配置文件
Resource resource = new ClassPathResource("beanFactoryTest.xml");
通过ClassPathResource 加载配置文件，并构建该实例的时候，是使用Resource接口进行定义的， 这也就说明了创建的实际上是Resource的实例，通过查看Resource 的源码不难发现，Resource对Java中将要使用的资源进行了抽象，Spring的设计中几乎所有可以加载资源的
类需要直接或间接的实现Resource 这个接口。下面可以看一下这个接口：
boolean exists(); // 判断是否资源是否存在
default boolean isReadable() { // 判断资源是否可读
return exists();
}
default boolean isOpen() { // 判断文件是否打开
return false;
}
default boolean isFile() { // 判断文件是否是文件系统中的文件，Spring5.0后加入的
return false;
}
URL getURL() throws IOException; // 获取文件的URL
URI getURI() throws IOException; // 获取文件的URI
File getFile() throws IOException; // 获取文件
default ReadableByteChannel readableChannel() throws IOException { // 返回一个Channel， 拥有最大效率的读操作
return Channels.newChannel(getInputStream());
}
long contentLength() throws IOException; // 返回资源解析后的长度
long lastModified() throws IOException; // 最后一次休干时间
Resource createRelative(String relativePath) throws IOException; // 基于当前资源创建一个相对资源
@Nullable
String getFilename(); // 获取文件名 for example, "myfile.txt"
String getDescription(); // 获取资源描述， 当发生错误时将被打印
通过查看源码，还有一点可以发现， Resource接口继承了InputStreamSource 接口，下面来看下这个接口：
public interface InputStreamSource {
/**
* Return an {@link InputStream} for the content of an underlying resource.
* <p>It is expected that each call creates a <i>fresh</i> stream.
* <p>This requirement is particularly important when you consider an API such
* as JavaMail, which needs to be able to read the stream multiple times when
* creating mail attachments. For such a use case, it is <i>required</i>
* that each {@code getInputStream()} call returns a fresh stream.
* @return the input stream for the underlying resource (must not be {@code null})
* @throws java.io.FileNotFoundException if the underlying resource doesn't exist
* @throws IOException if the content stream could not be opened
*/
InputStream getInputStream() throws IOException;
}
这个接口的作用非常简单并且是顶层接口，它的作用就是返回一个InputStream， 最简单的作用却提供了最大的方便， 因为所有资源加载类几乎都直接或间接的实现了Resource， 这也就意味着， 几乎所有的资源加载类都可以得到一个InputStream， 这将使得在资源加载之后能轻易地得到一个InputStream， 这非常重要。通过InputStream， Spring使所有的资源文件都能进行统一的管理了， 优点是不言而喻的。至于实现是非常简单的， ClassPathResource 中的实现方式便是通过class或者classLoader提供的底层方法进行调用的， 对于FileSystemResource的实现其实更加简单， 就是直接使用FileInputStream对文件进行实例化。
三、DefaultListableBeanFactory、XmlBeanDefinitionReader和BeanDefinitionRegistry
配置文件加载完成后进行的下一步操作是这样的，这和3.1之前的版本不太一样，至于为什么要弃用XmlBeanFactory（我猜是为了对其他部分进行设计，从而让这部分代码更加充分的进行解耦）：
BeanFactory beanFactory = new DefaultListableBeanFactory();
BeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader((BeanDefinitionRegistry) beanFactory);
beanDefinitionReader.loadBeanDefinitions(resource);配置文件加载完成后，创建了一个BeanFactory的实例。DefaultListableBeanFactory： 见名知意，这是一个默认可列的bean工厂类，注释用说道，典型的一个应用就是在第一次定义时注册所有bean。接下来的操作是利用多态将上一步创建的BeanFactory的实例转成BeanDefinitionRegistry， 因为下一步需要读取xml文件中定义的内容，这也就是XmlBeanDefinitionReader的作用，而XmlBeanDefinitionReader在实例化的时候需要一个bean的定义注册机，所以就进行了以上操作， 事实上：在创建BeanFactory实例时，同样可以定义为BeanDefinitionRegistry类型。下面详细说下一这三个类的作用：
- DefaultListableBeanFactory：在定义时通过当前类的类加载器（如果不存在就向上级加载器寻找直到系统加载器）下的所有的bean进行注册，注意这里只是进行注册而已。
- BeanDefinitionRegistry: 为了注册Spring持有的bean的一个接口，是在BeanFactory,AbstractBeanDefinition中间的一层接口。
- XmlBeanDefinitionReader：注释中这样写道
/**
* Bean definition reader for XML bean definitions.
* Delegates the actual XML document reading to an implementation
* of the {@link BeanDefinitionDocumentReader} interface.
*
* <p>Typically applied to a
* {@link org.springframework.beans.factory.support.DefaultListableBeanFactory}
* or a {@link org.springframework.context.support.GenericApplicationContext}.
*
* <p>This class loads a DOM document and applies the BeanDefinitionDocumentReader to it.
* The document reader will register each bean definition with the given bean factory,
* talking to the latter's implementation of the
* {@link org.springframework.beans.factory.support.BeanDefinitionRegistry} interface.
*/
只说最重要的一个部分， 在这里它需要委托一个真正的xml文档读取器来读取文档内容，也就是BeanDefinitionDocumentReader，而这个文档读取器将读取所有的bean注册内容，而这些资源正是1、2中所得到的。接下来就是重要的一步，beanDefinitionReader.loadBeanDefinitions(resource); 在解析了配置文件中的bean后，事实上配置文件中bean并没有被真正的加载，并且上面的步骤也只是对所有的bean进行了一次注册， 所以，这个时候load了resoure中的内容， 在编码没有问题以后，并且resource中bean可以在类加载器下找到这些类，这时就对这些bean进行加载，实例化。下面跟踪代码到这个实现中看看Spring 是怎么做的：
/**
* Create new XmlBeanDefinitionReader for the given bean factory.
* @param registry the BeanFactory to load bean definitions into,
* in the form of a BeanDefinitionRegistry
*/
public XmlBeanDefinitionReader(BeanDefinitionRegistry registry) {
super(registry);
}
protected AbstractBeanDefinitionReader(BeanDefinitionRegistry registry) {
Assert.notNull(registry, "BeanDefinitionRegistry must not be null");
this.registry = registry;
// Determine ResourceLoader to use.
if (this.registry instanceof ResourceLoader) {
this.resourceLoader = (ResourceLoader) this.registry;
}
else {
this.resourceLoader = new PathMatchingResourcePatternResolver();
}
// Inherit Environment if possible
if (this.registry instanceof EnvironmentCapable) {
this.environment = ((EnvironmentCapable) this.registry).getEnvironment();
}
else {
this.environment = new StandardEnvironment();
}
}
在实例化XmlBeanDefinitionReader 的过程中，在构造函数中调用了其超类的构造函数，而在超类中对其所处换环境进行的判断，所谓的环境呢，事实上指得就是是通过BeanFactory， 还是通过ApplicationContext加载的上下文，这也就意味着不同方式加载可能存在某些不同。写这些的目的其实是为了引出这里的一个我们十分关注的东西， 就是自动装配。在AbstractAutowireCapableBeanFactory这个抽象类的构造方法中实现了相关的自动装配，在BeanDefinitionRegistry 和DefaultListableBeanFactory中都继承了这个抽象类， 并在其构造函数内直接调用了其超类的构造函数也就是：
/**
* Create a new AbstractAutowireCapableBeanFactory.
*/
public AbstractAutowireCapableBeanFactory() {
super();
ignoreDependencyInterface(BeanNameAware.class);
ignoreDependencyInterface(BeanFactoryAware.class);
ignoreDependencyInterface(BeanClassLoaderAware.class);
}
这里有必要提及一下
ignoreDependencyInterface（）;这个方法。它的主要功能就是忽略接口中的自动装配， 那么这样做的目的是什么呢？会产生什么样的效果呢？举例来说， 当A中有属性B， 那么Spring在获取A的时候就会去先去获取B， 然而有些时候Spring不会这样做，就是Spring通过BeanNameAware、BeanFactoryAware和BeanClassLoaderAware进行注入的， 也就是根据环境的不同， Spring会选择相应的自从装配的方式。在不是当前环境中的注入，Spring并不会再当前环境对Bean进行自动装配。类似于，BeanFactory通过BeanFactoryAwar进行注入或者ApplicationContext通过ApplicationContextAware进行注入。
经过了这么长时间的铺垫，终于应该进入正题了， 就是进入通过loadBeanDefinitions（resource）方法加载这个文件。这个方法这样实现：
public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {
Assert.notNull(encodedResource, "EncodedResource must not be null");
if (logger.isTraceEnabled()) {
logger.trace("Loading XML bean definitions from " + encodedResource);
}
Set<EncodedResource> currentResources = this.resourcesCurrentlyBeingLoaded.get();
if (currentResources == null) {
currentResources = new HashSet<>(4);
this.resourcesCurrentlyBeingLoaded.set(currentResources);
}
if (!currentResources.add(encodedResource)) {
throw new BeanDefinitionStoreException(
"Detected cyclic loading of " + encodedResource + " - check your import definitions!");
}
try {
InputStream inputStream = encodedResource.getResource().getInputStream();
try {
InputSource inputSource = new InputSource(inputStream);
if (encodedResource.getEncoding() != null) {
inputSource.setEncoding(encodedResource.getEncoding());
}
return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
}
finally {
inputStream.close();
}
}
catch (IOException ex) {
throw new BeanDefinitionStoreException(
"IOException parsing XML document from " + encodedResource.getResource(), ex);
}
finally {
currentResources.remove(encodedResource);
if (currentResources.isEmpty()) {
this.resourcesCurrentlyBeingLoaded.remove();
}
}
}
这段代码很容易理解，不过真正实现的核心代码是在return doLoadBeanDefinitions(inputSource, encodedResource.getResource());这里实现的。下面是这个方法的核心代码：
protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
throws BeanDefinitionStoreException {
try {
Document doc = doLoadDocument(inputSource, resource);
int count = registerBeanDefinitions(doc, resource);
if (logger.isDebugEnabled()) {
logger.debug("Loaded " + count + " bean definitions from " + resource);
}
return count;
}
}
这段处理可以说非常容易了，对resource流进行再封装，封装为Docment对象，然后解析并注册这个doc中的bean对象，返回定义的bean的个数。在Spring3.1之前上面这个方法中还要验证加载Xml是否符合规范。而Spring5.x之后Spring将验证的工作放到了获取Document中。
三、获取Document
看一下Document doc = doLoadDocument(inputSource, resource);这个方法的源码：
protected Document doLoadDocument(InputSource inputSource, Resource resource) throws Exception {
return this.documentLoader.loadDocument(inputSource, getEntityResolver(), this.errorHandler,
getValidationModeForResource(resource), isNamespaceAware());
}
在这个方法中做了三件事：
- getEntityResolver();这个方法将根据当前的resource创建一个ResourceLoader实例，然后根据这个对ResourceLoader进行封装，封装为EntityResolver实例， 这个EntityResolver的作用是进行处理实体映射。
- getValidationModeForResource(); 这个方法的作用是获取资源的验证模式，通过自动或手动的方式对已经加载到的资源进行检验。这里是真正对xml文件进行验证的地方。
- isNamespaceAware(); 这个方法用来判断加载的xml文件是否支持明明空间。
实现上面方法的类继承了这个接口：DocumentLoader，并且实现了这个接口中的唯一的抽象：
/**
* Load a {@link Document document} from the supplied {@link InputSource source}.
* @param inputSource the source of the document that is to be loaded
* @param entityResolver the resolver that is to be used to resolve any entities
* @param errorHandler used to report any errors during document loading
* @param validationMode the type of validation
* {@link org.springframework.util.xml.XmlValidationModeDetector#VALIDATION_DTD DTD}
* or {@link org.springframework.util.xml.XmlValidationModeDetector#VALIDATION_XSD XSD})
* @param namespaceAware {@code true} if support for XML namespaces is to be provided
* @return the loaded {@link Document document}
* @throws Exception if an error occurs
*/Document loadDocument(
InputSource inputSource, EntityResolver entityResolver,
ErrorHandler errorHandler, int validationMode, boolean namespaceAware)
throws Exception;
那么详细讲一下上面提及的EntityResolver, 如果SAX（Simple API for XML：简单的来讲，它的作用就是不去构建DOM，而是以应用程序的方式以最有效率的方式实现XML与应用实体之间的映射；当然还有一种方式是解析DOM，具体两种方式，我也没有做过相应深入探究）应用驱动程序需要实现自定义的处理外部实体，在必须实现此接口并通过某种方式向SAX驱动器注册一个实例。这需要根据XML头部的DTD中的网络地址下载声明并认证，而EntityResolver实际上就是在提供一个寻dtd找声明的方法，这样就可以在项目中直接定义好声明，而通过本地寻找的方式避免了网络寻找的过程，编译器也避免了在网络延迟高或没有网络的情况下报错。
四、解析及注册BeanDefinitions
当文件转换为Document后，接下来提取及注册Bean就是我们后头的重头戏。事实上，这一部分内容并不会在我们的使用中出现了。
同样在XmlBeanDefinitionReader这个类中，可以发现随着Docment的获取完成后，直接做的是下面的这个事情registerBeanDefinitions();：
/**
* Register the bean definitions contained in the given DOM document.
* Called by {@code loadBeanDefinitions}.
* <p>Creates a new instance of the parser class and invokes
* {@code registerBeanDefinitions} on it.
* @param doc the DOM document
* @param resource the resource descriptor (for context information)
* @return the number of bean definitions found
* @throws BeanDefinitionStoreException in case of parsing errors
* @see #loadBeanDefinitions
* @see #setDocumentReaderClass
* @see BeanDefinitionDocumentReader#registerBeanDefinitions
*/
public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {
BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();
int countBefore = getRegistry().getBeanDefinitionCount();
documentReader.registerBeanDefinitions(doc, createReaderContext(resource));
return getRegistry().getBeanDefinitionCount() - countBefore;
}
作用在注释中写的很清楚，注册DOM文档（Spring的配置信息中. 也就是解析后的xml）中包含的bean。
- 首先创建一个bean定义文档读取器，这个对象是根据DefaultBeanDefinitionDocumentReader的class通过反射的方式来创建的，
DefaultBeanDefinitionDocumentReader实现了BeanDefinitionDocumentReader这个接口，这里唯一的抽象方法就是registerBeanDefinitions(Document doc, XmlReaderContext readerContext);，这也就意味着上面的第三行代码是一个自然的应用。
提示：这里的doc参数就是通过之前的doLoadDocument方法获得的，而这很好的应用了面向对象的单一职责原则， 将转换为Docment的复杂过程交给一个单一的类处理，而这个类就是BeanDefinitionDocumentReader， 事实上这是一个接口，而具体的实例化是在createBeanDefinitionDocumentReader这个方法中完成的。
- getRegistry();的作用实际上是获得一个BeanDefinitionRegistry对象。下面的图片是程序最开始时，容器开始实现时候的代码，这里可以看到BeanDefinitionRegistry这个接口。注意这里创建的BeanDefinitionRegistry是final的，也就是这里获取的是Spring发现的所有的bean个数,是不许改变的， 熟悉设计模式的同学肯定知道，这个BeanDefinitionRegistry是一个单例的。
- 而接下来做的就是就是，记录所有对我们的资源文件进行加载，这里是真正解析xml文件并加载的地方，而这个逻辑就是那么简单了， 先统计当前的bean defintions个数然后加载一些bean定义进来，然后在统计bean 的个数，然后用后来的减去开始的就是加载的。没错了，就是学前班加减法。
到这里我已经不想探究xml文件是如何读取的了，如果想看的话，可以去看下一篇《Spring源码一（容器的基本实现2）》！
