哪些循环依赖问题Spring解决不了?
- 前言
- 版本约定
- 正文
- 场景一: prototype 类型的循环依赖
- 场景二: constructor 注入的循环依赖
- 场景三:普通的 AOP 代理 Bean 的循环依赖--默认是可以的
- 场景四:@Async 增强的 Bean 的循环依赖
- 小结
- SpringIoC源码视频讲解:
前言
大家都知道 Spring 解决了循环依赖的问题,网上也可以搜到 Spring 是使用三级缓存来解决循环依赖的。
但有些时候循环依赖问题还是会导致启动报错。
也就说明,在某些情况下,Spring 是没有办法解决循环依赖问题的。
我们就来探究一下,哪些循环依赖场景是 Spring 没办法解决的?
版本约定
Spring 5.3.9 (通过 SpringBoot 2.5.3 间接引入的依赖)
正文
场景一: prototype 类型的循环依赖
描述: A --> B --> A,且 A,B 都是 scope=prototype
@Service
@Scope("prototype")
public class A {
@Autowired
private B b;
}
@Service
@Scope("prototype")
public class B {
@Autowired
private A a;
}
这种场景下会报如下错误:
Exception in thread "main" org.springframework.beans.factory.UnsatisfiedDependencyException:
Error creating bean with name 'c1Service': Unsatisfied dependency expressed through field 'c2Service';
nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'c2Service': Unsatisfied dependency expressed through field 'c1Service';
nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'c1Service': Requested bean is currently in creation: Is there an unresolvable circular reference?
分析:
A 实例创建后,populateBean 时,会触发 B 的加载。
B 实例创建后,populateBean 时,会触发 A 的加载。由于 A 的 scope=prototype,从缓存中获取不到 A,要创建一个全新的 A。
这样,就会进入一个死循环。Spring 肯定是解决不了这种情况下的循环依赖的。所以,提前进行了 check,并抛出了异常。
解决:
在需要循环注入的属性上添加 @Lazy
场景二: constructor 注入的循环依赖
描述: A --> B --> A,且 都是通过构造函数依赖的
@Service
public class A {
private B b;
public A(B b) {
this.b=b;
}
}
@Service
public class B {
private A a;
public B(A a) {
this.a=a;
}
}
这种场景下会报如下错:
Exception in thread "main" org.springframework.beans.factory.UnsatisfiedDependencyException:
Error creating bean with name 'c1' defined in file [/target/classes/com/kvn/beans/circle/constructor/C1.class]: Unsatisfied dependency expressed through constructor parameter 0;
nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'c2' defined in file [/target/classes/com/kvn/beans/circle/constructor/C2.class]: Unsatisfied dependency expressed through constructor parameter 0;
nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'c1': Requested bean is currently in creation: Is there an unresolvable circular reference?
分析:
A 实例在创建时(createBeanInstance),由于是构造注入,这时会触发 B 的加载。
B 实例在创建时(createBeanInstance),又会触发 A 的加载,此时,A 还没有添加到三级缓存中,所以就会创建一个全新的 A。
这样,就会进入一个死循环。Spring 是解决不了这种情况下的循环依赖的。所以,提前进行了 check,并抛出了异常。
如果对三级缓存的使用不清楚的话,可以点击传送门: Spring 是怎样解决循环依赖的
解决:
在需要循环注入的属性上添加 @Lazy
例如:public A(@Lazy B b){...}
场景三:普通的 AOP 代理 Bean 的循环依赖–默认是可以的
描述:
A --> B --> A, 且 A,B 都是普通的 AOP Proxy 类型的 bean
普通的 AOP proxy 类型指:通过用户自定义的 @Aspect 切面生成的代理 bean,区别于 @Async 标记的类产生的 AOP 代理
Spring 默认解决了 普通的 AOP 代理 Bean 的循环依赖
问题,这里单独拿出来,是为了与 @Async 增强的代理 Bean 场景
进行对比。
分析:
通常情况下, AOP proxy 的创建是在 initializeBean 的时候,通过 BeanPostProcessor 处理的。
A 在 createBeanInstance 之后,添加到三级缓存。populateBean 时触发 B 的加载。
B 在 createBeanInstance 之后,添加到三级缓存。populateBean 时触发 A 的加载,这时,三级缓存中有 A,那么通过三级缓存 ObjectFactory#get()
可以获取到 bean 的早期引用。
获取 bean 的早期引用的逻辑如下:
// AbstractAutowireCapableBeanFactory#getEarlyBeanReference()
/**
* Obtain a reference for early access to the specified bean, typically for the purpose of resolving a circular reference.
* 获取指定 bean 的早期引用,通常用于解析循环引用。
*/
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
Object exposedObject = bean;
if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
for (SmartInstantiationAwareBeanPostProcessor bp : getBeanPostProcessorCache().smartInstantiationAware) {
exposedObject = bp.getEarlyBeanReference(exposedObject, beanName);
}
}
return exposedObject;
}
普通的 AOP 代理都是通过 AbstractAutoProxyCreator
来生成代理类的,而 AbstractAutoProxyCreator 实现了 SmartInstantiationAwareBeanPostProcessor,所以,在通过三级缓存 getEarlyBeanReference()
的时候,就可以提前获取到最终暴露到 Spring 容器中的代理 bean 的早期引用。
public abstract class AbstractAutoProxyCreator extends ProxyProcessorSupport
implements SmartInstantiationAwareBeanPostProcessor, BeanFactoryAware {
......
}
所以,普通的 AOP 代理 bean 的循环依赖是没有问题的。
场景四:@Async 增强的 Bean 的循环依赖
描述:
A --> B --> A, 且 A 是被 @Async 标记的类
@Service
public class A {
@Autowired
private B b;
@Async
public void m1(){
}
}
@Service
public class B {
@Autowired
private A a;
}
这种场景会报如下错:
Exception in thread "main" org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'p1Service':
Bean with name 'p1Service' has been injected into other beans [p2Service] in its raw version as part of a circular reference, but has eventually been wrapped.
This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.
可能大家会有很深的疑问,刚刚场景三不是说 AOP 代理 bean 被循环依赖的场景是没有问题的,而 @Async 标记的类也是 AOP 代理,怎么就不行了呢?
那么,我们就要看 @Async 产生的代理和普通的 AOP 代理有什么区别了?
分析:
proxy 的创建是在 initializeBean 的时候,通过 BeanPostProcessor 处理的。
A 在 createBeanInstance 之后,添加到三级缓存。populateBean 时触发 B 的加载。
B 在 createBeanInstance 之后,添加到三级缓存。populateBean 时触发 A 的加载,这时,三级缓存中有 A,那么通过三级缓存 ObjectFactory#get() 可以获取到 bean 的早期引用。
普通的 AOP 代理都是通过 AbstractAutoProxyCreator
来生成代理类的,AbstractAutoProxyCreator 实现了 SmartInstantiationAwareBeanPostProcessor。
而 @Async 标记的类是通过 AbstractAdvisingBeanPostProcessor
来生成代理的,AbstractAdvisingBeanPostProcessor 没有实现 SmartInstantiationAwareBeanPostProcessor。
public abstract class AbstractAdvisingBeanPostProcessor extends ProxyProcessorSupport implements BeanPostProcessor {
.......
}
所以,这时通过 A 的三级缓存来获取 bean 的早期引用时,获取到的是 bean 的原始对象的引用,而不会提前生成代理对象。
这时 B 中注入的 A 对象不是代理对象。最后会导致 B 中持有的 A 对象与 Spring 容器中的 bean A 不是同一个对象。
这种情况显然是有问题的,跟我们的预期是不相符的,所以,Spring 在 initializeBean 之后,做了 check,检验二级缓存中的 bean 与最终暴露到 Spring 容器中的 bean 是否是相同的,如果不同,就会报错。
综上,@Async 标记的类产生的代理 bean 发生了循环依赖, Spring 默认是解决不了的。
二级缓存中存放的是 bean 的早期引用,与最终暴露到容器中的 bean 的引用必须是相同的。
如果最终暴露的 AOP 代理 bean 与 三级缓存中获取到的早期引用 不是同一个对象引用的话,那就说明被循环依赖注入的 bean 与最终暴露到 Spring 容器中的 bean 不相同,这样是不被允许的。
Spring 通过检查的机制,check 检验二级缓存中的 bean 与最终暴露到 Spring 容器中的 bean 是否是相同的,如果不同,就会报错。
如果对三级缓存的使用不清楚的话,可以点击传送门: Spring 是怎样解决循环依赖的
解决:
在需要循环注入的属性上添加 @Lazy
小结
Spring 为我们解决了循环依赖的问题。下面这些情况下,默认是解决不了循环依赖问题的:
- prototype 类型的循环依赖
- constructor 注入的循环依赖
- @Async 类型的 AOP Bean 的循环依赖
这些解决不了的场景都可以通过 @Lazy 来解决掉。
思考:
可能大家又有疑问了:为什么使用了 @Lazy 之后,就可以解决掉这些情况下的循环依赖问题呢?
后续的文章会继续解开这个疑惑…