概念
IOC(Inversion Of Control),即控制反转,或者说DI(Dependency Injection),依赖注入,都属于Spring中的一种特点,可以统称为IOC
- 控制反转,即控制权的反转,也就是说将内置对象创建的控制权交给第三方容器,而不是本身的对象
- 依赖注入,即将依赖对象进行注入,也就是说不主动创建对象,而是通过第三方容器将依赖的对象注入进来
不管是IOC还是DI,它们都有一个共同的特点,即通过第三方容器来管理对象的创建、初始化、注入、销毁,在Spring中,这些容器中的对象统称为bean,使用的时候只需要通过xml或Java的配置就能够很方便地将一个对象声明为容器中的bean,并且可以通过@Autowired注解等方法将这些bean注入到需要的地方,我们接下来就要深入地了解一下Spring中IOC到底是怎么实现的
BeanFactory
顾名思义,BeanFactory就是Bean的工厂,也就是Bean的容器,BeanFactory作为容器接口,我们暂不关心它的实现类,先了解一下它本身的特性,点进BeanFactory的源码,我们只看以下这几个重要的方法,其余方法用到的时候再说
/** 通过name获取bean实例 */
Object getBean(String name) throws BeansException;
/** 通过name和对象类型获取bean实例 */
<T> T getBean(String name, Class<T> requiredType) throws BeansException;
/** 得到bean的别名,如果通过别名索引,则原名也会被检索出 */
String[] getAliases(String name);
这几个方法看起来很简单,别急,这只是在接口中的定义,Spring提供了很多BeanFactory的实现类,比如ApplicationContext等
BeanDefinition
bean当然不能用普通的对象来描述,在spring中,bean被封装成BeanDefinition,如下:
Bean资源的加载过程
资源的加载,也可以是认为是容器的初始化,可以分为以下三个部分:
- 定位资源
- 载入资源
- 注册资源
比如XmlWebApplicationContext就是从xml文件中加载资源,我们这里以ClassPathXmlApplicationContext为例,了解一下xml文件中的配置是怎么加载到Spring容器中的
首先是构造方法,如下:
/**
* @param configLocations 资源路径
* @param refresh 是否自动刷新容器
* @parent parent 容器的父类
*/
public ClassPathXmlApplicationContext(
String[] configLocations, boolean refresh, @Nullable ApplicationContext parent)
throws BeansException {
super(parent);
setConfigLocations(configLocations);
if (refresh) {
refresh();
}
}
先来看这个super(parent),我们一路找上去,发现每一层都调用了super(parent),直到进入AbstractApplicationContext类中,发现调用了一个this()方法,这个方法详细如下:
public AbstractApplicationContext() {
this.resourcePatternResolver = getResourcePatternResolver();
}
从字面上理解,应该是类似设置资源解析器之类的方法,我们进入这个方法,发现其实际上创建了一个PathMatchingResourcePatternResolver对象,同时设置我们的最顶层容器为resourceLoader资源加载器,看到这里就差不多了解了,super(parent)实际上就是设置了bean的资源加载器
我们接着看setConfigLocations(configLocations)方法,源码如下:
public void setConfigLocations(@Nullable String... locations) {
if (locations != null) {
Assert.noNullElements(locations, "Config locations must not be null");
this.configLocations = new String[locations.length];
for (int i = 0; i < locations.length; i++) {
this.configLocations[i] = resolvePath(locations[i]).trim();
}
}
else {
this.configLocations = null;
}
}
这个方法是继承而来的,是AbstractRefreshableConfigApplicationContext的一个方法,在这个方法内部,设置了configLocations的值为资源路径(进行环境变量填补充并去除空格),可以理解为对资源进行定位
也就是说,容器在创建出来时,做了以下两件事(不包括刷新容器操作):
- 设置资源解析器
- 设置资源路径,进行资源定位
然后我们再来看这个可选的refresh()方法,这是从AbstractApplicationContext继承而来的方法,源码如下:
@Override
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
// 获取当前时间,同时设置同步标识,避免多线程下冲突
prepareRefresh();
// 实际调用了子类的refreshBeanFactory方法,同时返回子类的beanFactory
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// 设置容器属性
prepareBeanFactory(beanFactory);
try {
// 为子类beanFactory指定BeanPost事件处理器
postProcessBeanFactory(beanFactory);
// 调用注册为bean的事件处理器
invokeBeanFactoryPostProcessors(beanFactory);
// 注册BeanPost事件处理器,用于监听容器创建
registerBeanPostProcessors(beanFactory);
// 初始化消息源
initMessageSource();
// 初始化事件传播器
initApplicationEventMulticaster();
// 在特定的子类中初始化其他特殊的bean
onRefresh();
// 检查并注册监听器
registerListeners();
// 初始化剩余的单例
finishBeanFactoryInitialization(beanFactory);
// 最后一步:初始化容器生命周期处理器,并发布容器生命周期事件
finishRefresh();
}
catch (BeansException ex) {
if (logger.isWarnEnabled()) {
logger.warn("Exception encountered during context initialization - " +
"cancelling refresh attempt: " + ex);
}
// 销毁创建的单例,以避免悬置资源
destroyBeans();
// 重置同步标识
cancelRefresh(ex);
throw ex;
}
finally {
// 因为不需要单例bean中元数据,所以重置spring的自检缓存
resetCommonCaches();
}
}
}
配合注释,就能差不多了解了执行过程,实际就是初始化并注册一系列处理器和监听器的过程,有人可能会发现,怎么没有加载资源的过程,别急,我们进入obtainFreshBeanFactory()方法,其中有一个refreshBeanFactory()方法,我们点开AbstractRefreshableApplicationContext中的实现:
@Override
protected final void refreshBeanFactory() throws BeansException {
if (hasBeanFactory()) {
destroyBeans();
closeBeanFactory();
}
try {
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);
}
}
发现了吗,这里有一个loadBeanDefinitions()方法,会根据选用的xml解析还是注解解析调用子类中的方法,再接下来的解析过程就不是我们分析的重点了,如果以后有时间,我会再写一篇来专门分析解析过程的文章
到这里,整个加载过程就清晰了
依赖注入的过程
一开始,我们就介绍了getBean(name)方法,那么我们接下来,就要详细的来进行分析这个方法到底是怎么把我们需要的bean创建并交给我们的
这个方法有两种常见的实现,AbstractBeanFactory和AbstractApplicationContext,而实际上AbstractApplicationContext也是调用了AbstractBeanFactory的方法,所以我们就只看AbstractBeanFactory即可
在这个方法内部调用了doGetBean方法,我们进入方法内部,如下:
protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType,
@Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {
final String beanName = transformedBeanName(name);
Object bean;
// Eagerly check singleton cache for manually registered singletons.
Object sharedInstance = getSingleton(beanName);
if (sharedInstance != null && args == null) {
if (logger.isTraceEnabled()) {
if (isSingletonC