一、Spring 容器高层视图
Spring启动时读取应用程序提供的Bean配置信息,并在Spring容器中生成一份相应的Bean配置注册表,然后根据这张注册表实例化Bean,装配好Bean之间的依赖关系,为上层应用提供准备就绪的运行环境。
二、内部工作机制
该图描述了Spring容器从加载配置文件到创建出一个完整Bean的作业流程:
1、ResourceLoader从存储介质中加载Spring配置信息,并使用Resource表示这个配置文件的资源。
2、BeanDefinitionReader读取Resource所指向的配置文件资源(一般是applicationContext.xml文件),然后解析配置文件。配置文件中每一个<bean>解析成一个BeanDefinition对象,并保存到BeanDefinitionRegistry中。
3、容器扫描BeanDefinitionRegistry中的BeanDefinition,使用Java的反射机制自动识别出Bean工厂后处理器(就是实现了BeanFactoryPostProcessor接口的Bean,这个处理器也是一个Bean),然后调用这些Bean工厂后处理器对BeanDefinitionRegistry中的BeanDefinition进行加工处理。主要完成以下两项工作:
3.1)对使用到占位符的<bean>元素标签进行解析,得到最终的配置值,这意味对一些半成品式的BeanDefinition对象进行加 工处理并得到成品的BeanDefinition对象。
3.2)对BeanDefinitionRegistry中的BeanDefinition进行扫描,通过Java反射机制找出所有属性编辑器(就是实现了java.beans.PropertyEditor接口的Bean,这个编辑器也是一个Bean),并自动将它们注册到Spring容器的PropertyEditorRegistry(属性编辑器注册表)中。
4.Spring容器从BeanDefinitionRegistry中取出加工后的BeanDefinition,并调用InstantiationStrategy着手进行Bean实例化的工作。
5.在实例化Bean时,Spring容器使用BeanWrapper对Bean进行封装,BeanWrapper提供了很多以Java反射机制操作Bean的方法,它将结合该Bean的BeanDefinition以及容器中属性编辑器,完成Bean属性的设置工作。
6.利用容器中注册的Bean后处理器(就是实现了BeanPostProcessor接口的Bean,这个处理器也是一个Bean)对已经完成属性设置工作的Bean进行后续加工,直接装配出一个准备就绪的Bean。
查看Spring框架的源码时,有两条清晰可见的脉络:
1)接口层描述了容器的重要组件及组件间的协作关系,构建好Spring的骨架
2)继承体系逐步实现组件的各项功能,最终让Spring成为有血有肉的完整的框架
Spring组件按其所承担的角色可以划分为两类:
1)物料组件:Resource、BeanDefinition、PropertyEditor以及最终的Bean等,它们是加工流程中被加工、被消费的组件,就像流水线上被加工的物料;
2)加工设备组件:ResourceLoader、BeanDefinitionReader、BeanFactoryPostProcessor、InstantiationStrategy以及BeanWrapper等组件像是流水线上不同环节的加工设备,对物料组件进行加工处理。
ClassPathXmlApplicationContext 类体系结构:
左边黄色部分是ApplicationContext体系继承结构,右边是BeanFactory的结构体系,两个结构是典型模板方法设计模式的使用。
从该继承体系可以看出:
1.BeanFactory是一个bean工厂的最基本定义,是一个很纯粹的bean工厂,不关注资源、资源位置、事件等。
2.ApplicationContext 是一个容器的最基本接口定义,它继承了BeanFactory,拥有工厂的基本方法。同时继承了ApplicationEventPublisher 、 MessageSource 、ResourcePatternResolver等接口,使其具有了一些额外的功能,如资源、事件等。
3.AbstractBeanFactory 和 AbstractAutowireCapableBeanFactory 是两个模板抽象工厂类。AbstractBeanFactory提供了bean工厂的抽象基类,同时提供了ConfigurableBeanFactory的完整实现。AbstractAutowireCapableBeanFactory是继承了AbstractBeanFactory的抽象工厂,里面提供了bean创建的支持,包括bean的创建、依赖注入、检查等等功能,是一个核心的bean工厂基类。
4.ClassPathXmlApplicationContext之所以拥有bean工厂的功能是通过持有一个真正的bean工厂DefaultListableBeanFactory的实例,并通过代理该工厂完成。
5.ClassPathXmlApplicationContext的初始化过程是对本身容器的初始化,同时也是对其持有的DefaultListableBeanFactory的初始化。
类体系结构这部分转自:【Spring】IOC核心源码学习:容器初始化过程
三、Spring容器-ApplicationContext的启动过程
从以上类结构体系中,可以看出ApplicationContext继承了BeanFactory对象,来实现对容器的操作,初始化完成之后,BeanFactory封装了bean的信息,而ApplicationContext通过访问这个对象获取bean的对象信息(BeanDefinition/Bean对象,都是由BeanFactory实际创建并管理的),为了实现接口的统一,ApplicationContext也实现了一系列的BeanFactory接口(可以说ApplicationContext对BeanFactory对象实现一种代理)。ApplicationContext建立在BeanFactory的基础之上,对配置对象的管理最终还是交于一个DefaultListableBeanFactory来完成(装配地址/访问等),而ApplicationContext在应用这个DefaultListableBeanFactory对象的基础上,不仅实现了BeanFactory接口提供的功能方法,并且黏合了一些面向应用的功能,如资源/国际化支持/框架事件支持等,并且将一些原先需要手动设置到BeanFactory的属性通过配置文件中配置的形式代替(如工厂后处理器BeanPostProcessor/InstantiationAwareBeanPostProcessor)。
同样,因为对于BeanDefinition和bean对象的管理是由上下文持有的beanfactory对象完成的,用户不需要拥有这样的接口,因此,ApplicationContext的接口体系中不再有BeanDefinitionRegistry,SingletonBeanRegistry以及AutowireCapableBeanFactory接口。
Spring容器ApplicationContext的初始化
(一) 首先来看创建ApplicationContext ,以其子类ClassPathXmlApplicationContext为例:
ApplicationContext = new ClassPathXmlApplicationContext(xmlPath);
ClassPathXmlApplicationContext源码如下:
public class ClassPathXmlApplicationContext extends AbstractXmlApplicationContext {
private Resource[] configResources;
public ClassPathXmlApplicationContext() {
}
//。。。。。。省略几个重载的构造函数
public ClassPathXmlApplicationContext(String[] paths, Class<?> clazz, ApplicationContext parent)
throws BeansException {
super(parent);
Assert.notNull(paths, "Path array must not be null");
Assert.notNull(clazz, "Class argument must not be null");
this.configResources = new Resource[paths.length];
for (int i = 0; i < paths.length; i++) {
this.configResources[i] = new ClassPathResource(paths[i], clazz);
}
//IOC容器初始化过程
refresh();
}
关键就是refresh()方法,该方法负责容器的初始化,此方法被重写在AbstractApplicationContext接口中。
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
// Prepare this context for refreshing.
prepareRefresh();
// Tell the subclass to refresh the internal bean factory.
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// Prepare the bean factory for use in this context.
prepareBeanFactory(beanFactory);
try {
// Allows post-processing of the bean factory in context subclasses.
postProcessBeanFactory(beanFactory);
// Invoke factory processors registered as beans in the context.
invokeBeanFactoryPostProcessors(beanFactory);
// Register bean processors that intercept bean creation.
registerBeanPostProcessors(beanFactory);
// Initialize message source for this context.
initMessageSource();
// Initialize event multicaster for this context.
initApplicationEventMulticaster();
// Initialize other special beans in specific context subclasses.
onRefresh();
// Check for listener beans and register them.
registerListeners();
// Instantiate all remaining (non-lazy-init) singletons.
finishBeanFactoryInitialization(beanFactory);
// Last step: publish corresponding event.
finishRefresh();
}
catch (BeansException ex) {
if (logger.isWarnEnabled()) {
logger.warn("Exception encountered during context initialization - " +
"cancelling refresh attempt: " + ex);
}
// Destroy already created singletons to avoid dangling resources.
destroyBeans();
// Reset 'active' flag.
cancelRefresh(ex);
// Propagate exception to caller.
throw ex;
}
finally {
// Reset common introspection caches in Spring's core, since we
// might not ever need metadata for singleton beans anymore...
resetCommonCaches();
}
}
}
解释如下: