文章目录
一、bean的生命周期
1、简单来说spring bean的生命周期一共分为以下4个步骤
实例化 -> 属性赋值 -> 初始化 -> 销毁
1、 实例化
createBeanInstance:实例化,其实也就是调用对象的构造方法实例化对象
bean的实例化一共有三种方式
1)普通的构造方式实现
2)静态工厂创建
3)实例工厂创建
我们常用的实例化bean方式是 普通的构造方法创建
2、属性赋值
populateBean:填充属性,这一步主要是多bean的依赖属性进行填充
属性赋值一共又三种方式
1)set方式
2)构造器的方式
3)p命名空间的方式
3、初始化
initializeBean:调用spring 中的InitializingBean方法
/**
* 当需要在BeanFactory设置完bean的所有属性后,还需做一些初始化的操作,可让该bean实现此接口
*/
public interface InitializingBean {
/**
* 由BeanFactory在设置完bean的属性后调用
* 该方法可用于实现bean的初始化操作,不过需要在bean的属性设置完毕后(从名字也可以看出)
*/
void afterPropertiesSet() throws Exception;
}
1、spring有两种初始化bean的方式,实现InitializingBean接口以及配置init-method方法,两种方式可以同时使用,实现接口的方式比指定init-method先调用。
2、如果调用afterPropertiesSet方法时出错,则不调用init-method指定的方法。
4、销毁
二、spring bean的属性
1.引入库
Spring bean的几个属性:scope、init-method、destroy-method、depends-on等
1、Scope
- 在Spring容器中是指其创建的Bean对象相对于其他Bean对象的请求可见范围。 scope包含的分类:singleton, prototype, request, session, global session
2、init-method
- 是指创建bean时调用的方法,注意,不是创建bean的方法。
3、destroy-method
- 是指销毁bean时调用的方法,同样,不是销毁bean的方法。
4、 depends-on
- 用于指定bean初始化及销毁时的顺序
Spring 允许 Bean 在初始化完成后以及销毁前执行特定的操作。下面是常用的三种指定特定操作的方法:
通过实现 InitializingBean / DisposableBean 接口;
通过<bean> 元素的 init-method / destroy-method属性;
通过@PostConstruct或@PreDestroy注解。
Bean在实例化的过程中:Constructor > @PostConstruct >InitializingBean > init-method
Bean在销毁的过程中:@PreDestroy > DisposableBean > destroy-method
二、spring bean 循环依赖
通过单例bean初始化步骤我们可以知道,循环依赖主要发生在实例化、属性赋值。也就是构造器循环依赖和field循环依赖。
Spring为了解决单例的循环依赖问题,使用了三级缓存
这三级缓存分别指:
- singletonFactories : 单例对象工厂的cache
- earlySingletonObjects :提前暴光的单例对象的Cache
- singletonObjects:单例对象的cache
我们在创建bean的时候,首先想到的是从cache中获取这个单例的bean,这个缓存就是singletonObjects
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
synchronized (this.singletonObjects) {
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null && allowEarlyReference) {
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
singletonObject = singletonFactory.getObject();
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
return (singletonObject != NULL_OBJECT ? singletonObject : null);
}
上面的代码需要解释两个参数:
- isSingletonCurrentlyInCreation()判断当前单例bean是否正在创建中,也就是有没有初始化完成(比如A的构造器依赖了B对象所以得先去创建B对象, 或则在A的populateBean过程中依赖了B对象,得先去创建B对象,这时的A就是处于创建中的状态。)
- allowEarlyReference 是否允许从singletonFactories中通过getObject拿到对象
分析getSingleton()的整个过程,Spring首先从一级缓存singletonObjects中获取。如果获取不到,并且对象正在创建中,就再从二级缓存earlySingletonObjects中获取。如果还是获取不到且允许singletonFactories通过getObject()获取,就从三级缓存singletonFactory.getObject()(三级缓存)获取,如果获取到了则
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
从singletonFactories中移除,并放入earlySingletonObjects中。其实也就是从三级缓存移动到了二级缓存。
从上面三级缓存的分析,我们可以知道,Spring解决循环依赖的诀窍就在于singletonFactories这个三级cache。这个cache的类型是ObjectFactory
总结
让我们来分析一下“A的某个field或者setter依赖了B的实例对象,同时B的某个field或者setter依赖了A的实例对象”这种循环依赖的情况。A首先完成了初始化的第一步,并且将自己提前曝光到singletonFactories中,此时进行初始化的第二步,发现自己依赖对象B,此时就尝试去get(B),发现B还没有被create,所以走create流程,B在初始化第一步的时候发现自己依赖了对象A,于是尝试get(A),尝试一级缓存singletonObjects(肯定没有,因为A还没初始化完全),尝试二级缓存earlySingletonObjects(也没有),尝试三级缓存singletonFactories,由于A通过ObjectFactory将自己提前曝光了,所以B能够通过ObjectFactory.getObject拿到A对象(虽然A还没有初始化完全,但是总比没有好呀),B拿到A对象后顺利完成了初始化阶段1、2、3,完全初始化之后将自己放入到一级缓存singletonObjects中。此时返回A中,A此时能拿到B的对象顺利完成自己的初始化阶段2、3,最终A也完成了初始化,进去了一级缓存singletonObjects中,而且更加幸运的是,由于B拿到了A的对象引用,所以B现在hold住的A对象完成了初始化。
知道了这个原理时候,肯定就知道为啥Spring不能解决“A的构造方法中依赖了B的实例对象,同时B的构造方法中依赖了A的实例对象”这类问题了!因为加入singletonFactories三级缓存的前提是执行了构造器,所以构造器的循环依赖没法解决。