Spring IOC源码剖析：lazy-init 延迟加载机制和循环依赖问题
1、 lazy-init 延迟加载机制原理
1、lazy-init 延迟加载机制分析
普通 Bean 的初始化是在容器启动初始化阶段执行的，而被lazy-init=true修饰的 bean 则是在从容器里第?次进行context.getBean() 时进行触发。Spring 启动的时候会把所有bean信息(包括XML和注解)解 析转化成Spring能够识别的BeanDefinition并存到Hashmap里供下?的初始化时用，然后对每个 BeanDefinition 进行处理，如果是懒加载的则在容器初始化阶段不处理，其他的则在容器初始化阶段进行初始化并依赖注入。
public void preInstantiateSingletons() throws BeansException {
// 所有beanDefinition集合List<String> beanNames = new ArrayList<String>(this.beanDefinitionNames);// 触发所有?懒加载单例bean的初始化for (String beanName : beanNames) {
// 获取bean 定义RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);// 判断是否是懒加载单例bean，如果是单例的并且不是懒加载的则在容器创建时初始化if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {
// 判断是否是 FactoryBeanif (isFactoryBean(beanName)) {
final FactoryBean<?> factory = (FactoryBean<?>) getBean(FACTORY_BEAN_PREFIX + beanName);boolean isEagerInit;if (System.getSecurityManager() != null && factory instanceof SmartFactoryBean) {
isEagerInit = AccessController.doPrivileged(newPrivilegedAction<Boolean>() {
@Overridepublic Boolean run() {
return ((SmartFactoryBean<?>) factory).isEagerInit();}}, getAccessControlContext());}}else {
/*如果是普通bean则进行初始化并依赖注入，此 getBean(beanName)接下来触发的逻辑和懒加载时 context.getBean("beanName") 所触发的逻辑是?样的*/getBean(beanName);}}}
}
总结
- 对于被修饰为lazy-init的bean Spring 容器初始化阶段不会进行 init 并且依赖注入，当第?次 进行getBean时候才进行初始化并依赖注入
- 对于非懒加载的bean，getBean的时候会从缓存里头获取，因为容器初始化阶段 Bean 已经初始化完成并缓存了起来
2、 Spring IoC循环依赖问题
2.1、 什么是循环依赖
循环依赖其实就是循环引用，也就是两个或者两个以上的 Bean 互相持有对方，最终形成闭环。比如A 依赖于B，B依赖于C，C又依赖于A。
注意，这里不是函数的循环调用，是对象的相互依赖关系。循环调用其实就是?个死循环，除非有终结条件。
Spring中循环依赖场景有：
- 构造器的循环依赖（构造器注入）
- Field 属性的循环依赖（set注入）
其中，构造器的循环依赖问题无法解决，只能拋出 BeanCurrentlyInCreationException 异常，在解决 属性循环依赖时，spring采用的是提前暴露对象的方法。
2.2、 循环依赖处理机制
- 单例 bean 构造器参数循环依赖（无法解决）
- prototype 原型 bean循环依赖（无法解决）
对于原型bean的初始化过程中不论是通过构造器参数循环依赖还是通过setXxx方法产?循环依赖，Spring都会直接报错处理。
AbstractBeanFactory.doGetBean()方法：
if (isPrototypeCurrentlyInCreation(beanName)) {
throw new BeanCurrentlyInCreationException(beanName);
}
protected boolean isPrototypeCurrentlyInCreation(String beanName) {
Object curVal = this.prototypesCurrentlyInCreation.get();return (curVal != null && (curVal.equals(beanName) || (curVal instanceof Set && ((Set<?>) curVal).contains(beanName))));
}
在获取bean之前如果这个原型bean正在被创建则直接抛出异常。原型bean在创建之前会进行标记 这个beanName正在被创建，等创建结束之后会删除标记
try {
//创建原型bean之前添加标记beforePrototypeCreation(beanName);//创建原型beanprototypeInstance = createBean(beanName, mbd, args);
}
finally {
//创建原型bean之后删除标记afterPrototypeCreation(beanName);
}
总结：
Spring 不支持原型 bean 的循环依赖。
单例bean通过setXxx或者@Autowired进行循环依赖
Spring 的循环依赖的理论依据基于 Java 的引用传递，当获得对象的引用时，对象的属性是可以延后设置的，但是构造器必须是在获取引用之前 Spring通过setXxx或者@Autowired方法解决循环依赖其实是通过提前暴露?个ObjectFactory对 象来完成的，简单来说ClassA在调用构造器完成对象初始化之后，在调用ClassA的setClassB方法 之前就把ClassA实例化的对象通过ObjectFactory提前暴露到Spring容器中。
- Spring容器初始化ClassA通过构造器初始化对象后提前暴露到Spring容器。
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
if (logger.isDebugEnabled()) {
logger.debug("Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references");
}
//将初始化后的对象提前已ObjectFactory对象注入到容器中
addSingletonFactory(beanName, new ObjectFactory<Object>() {
@Overridepublic Object getObject() throws BeansException {
return getEarlyBeanReference(beanName, mbd, bean);}});
}
- ClassA调用setClassB方法，Spring?先尝试从容器中获取ClassB，此时ClassB不存在Spring 容器中。
- Spring容器初始化ClassB，同时也会将ClassB提前暴露到Spring容器中
- ClassB调用setClassA方法，Spring从容器中获取ClassA ，因为第?步中已经提前暴露了 ClassA，因此可以获取到ClassA实例
- ClassA通过spring容器获取到ClassB，完成了对象初始化操作。
- 这样ClassA和ClassB都完成了对象初始化操作，解决了循环依赖问题。