Spring IOC源码剖析：lazy-init 延迟加载机制和循环依赖问题

Posted 2021-06-27 丿涛哥哥

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()) {
			// 判断是否是 FactoryBean
			if (isFactoryBean(beanName)) {
				final FactoryBean<?> factory = (FactoryBean<?>) getBean(FACTORY_BEAN_PREFIX + beanName);
 				boolean isEagerInit;
 				if (System.getSecurityManager() != null && factory instanceof SmartFactoryBean) {
 					isEagerInit = AccessController.doPrivileged(new
						PrivilegedAction<Boolean>() {
							@Override
 							public 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);
     //创建原型bean
     prototypeInstance = 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>() {
    @Override
    public 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都完成了对象初始化操作，解决了循环依赖问题。