前言
我们都知道Spring解决了Setter注入或者Field注入的循环依赖问题，依靠的是三个Map(earlySingletonObjects、singletonFactories、singletonObjects)，网上有许多资料分析了原理，此文就不再赘述。但是，构造器注入下的循环依赖，Spring并没有直接解决，因此网上有许多文章都会说Spring的构造器注入循环依赖无解，实则不然，Spring提供了一些机制来确保即便是在构造器循环依赖的场景下，程序仍然能够正常工作
注：本文提及的循环依赖指Bean的作用域为默认的Singleton，而非Prototype
案例
首先，虚构一个Spring构造器注入循环依赖的案例，如下所示，Foo在构造器中声明依赖Bar，同时Bar在构造器中声明依赖Foo
@Component
public class Foo {
private Bar bar;
public Foo(Bar bar) {
this.bar = bar;
}
}
@Component
public class Bar {
private Foo foo;
public Bar(Foo foo) {
this.foo = foo;
}
}
启动应用，程序直接报错：
The dependencies of some of the beans in the application context form a cycle:
┌─────┐
| bar defined in file [.../target/classes/com/example/demo/service/Bar.class]
↑ ↓
| foo defined in file [.../target/classes/com/example/demo/service/Foo.class]
└─────┘
解决方案
在Foo的构造函数或者Bar的构造函数中使用@Lazy注解
如下所示，本文在Foo类的构造函数参数中使用了@Lazy注解对依赖的Bar进行了标注
@Component
public class Foo {
private Bar bar;
public Foo(@Lazy Bar bar) {
this.bar = bar;
}
}
启动应用，程序正常运行，如此，便解决了构造器循环依赖的问题
看到此处，不知是否有种恍然大悟但又没抓住其中关键点的感觉，如果有，请接着往下浏览
原理分析
本文源码基于 Spring 5.1.11.RELEASE
- 构造Foo实例时，检测到构造函数有强依赖的Bar实例需要注入，则走如下逻辑
// org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#createBeanInstance
// Candidate constructors for autowiring?
Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);
if (ctors != null || mbd.getResolvedAutowireMode() == AUTOWIRE_CONSTRUCTOR ||
mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args)) {
return autowireConstructor(beanName, mbd, ctors, args);
}
- 接着，通过ConstructorResolver#resolveAutowiredArgument解析构造器的参数，解析的含义是：根据构造器参数类型从IoC中找到(或者生成)对应的实例。该类本身并不具备解析依赖的能力，本质上还是依靠AutowireCapableBeanFactory#resolveDependency来进行依赖的解析。此处有一点需要注意的是，AutowireCapableBeanFactory#resolveDependency的第一个入参是
new DependencyDescriptor(param, true)，其中的'true'代表的含义是：该依赖项是强依赖，即required，如果找不到，会抛出NoSuchBeanDefinitionException。这也是Spring4以后官方推荐使用构造器注入的原因之一: 表明强依赖强系
// org.springframework.beans.factory.support.ConstructorResolver#resolveAutowiredArgument
protected Object resolveAutowiredArgument(MethodParameter param, String beanName,
@Nullable Set<String> autowiredBeanNames, TypeConverter typeConverter, boolean fallback) {
// beanName = foo
// paramType = Bar.class
Class<?> paramType = param.getParameterType();
if (InjectionPoint.class.isAssignableFrom(paramType)) {
InjectionPoint injectionPoint = currentInjectionPoint.get();
if (injectionPoint == null) {
throw new IllegalStateException("No current InjectionPoint available for " + param);
}
return injectionPoint;
}
// 走到熟悉的beanFactory.resolveDependency方法
return this.beanFactory.resolveDependency(
new DependencyDescriptor(param, true), beanName, autowiredBeanNames, typeConverter);
// ... (省略)
}
- 接着，便来到了熟悉的AutowireCapableBeanFactory#resolveDependency，此处会处理@Lazy注解，通过方法名
getLazyResolutionProxyIfNecessary我们可以大胆猜测：使用代理的方式处理@Lazy
// org.springframework.beans.factory.support.DefaultListableBeanFactory#resolveDependency
public Object resolveDependency(DependencyDescriptor descriptor, @Nullable String requestingBeanName, @Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException {
// ...(省略)
// 处理@Lazy的Case
Object result = getAutowireCandidateResolver().getLazyResolutionProxyIfNecessary(
descriptor, requestingBeanName);
if (result == null) {
result = doResolveDependency(descriptor, requestingBeanName, autowiredBeanNames, typeConverter);
}
return result;
}
- 接着，先判断依赖项是否含有@Lazy注解，如果含有，通过
buildLazyResolutionProxy方法生成代理对象返回
```
// org.springframework.context.annotation.ContextAnnotationAutowireCandidateResolver#getLazyResolutionProxyIfNecessary
public Object getLazyResolutionProxyIfNecessary(DependencyDescriptor descriptor, @Nullable String beanName) {
return (isLazy(descriptor) ? buildLazyResolutionProxy(descriptor, beanName) : null);
}
// 判断依赖项里是否含有@Lazy注解
protected boolean isLazy(DependencyDescriptor descriptor) {
for (Annotation ann : descriptor.getAnnotations()) {
Lazy lazy = AnnotationUtils.getAnnotation(ann, Lazy.class);
if (lazy != null && lazy.value()) {
return true;
}
}
MethodParameter methodParam = descriptor.getMethodParameter();
if (methodParam != null) {
Method method = methodParam.getMethod();
if (method == null || void.class == method.getReturnType()) {
Lazy lazy = AnnotationUtils.getAnnotation(methodParam.getAnnotatedElement(), Lazy.class);
if (lazy != null && lazy.value()) {
return true;
}
}
}
return false;
}
```
// 对依赖项生成代理对象
protected Object buildLazyResolutionProxy(final DependencyDescriptor descriptor, final @Nullable String beanName) {
Assert.state(getBeanFactory() instanceof DefaultListableBeanFactory,
"BeanFactory needs to be a DefaultListableBeanFactory");
final DefaultListableBeanFactory beanFactory = (DefaultListableBeanFactory) getBeanFactory();
// 稍微记一下TargetSource[目标源]，下文还要用到
TargetSource ts = new TargetSource() {
// ...(省略)
};
ProxyFactory pf = new ProxyFactory();
pf.setTargetSource(ts);
Class<?> dependencyType = descriptor.getDependencyType();
if (dependencyType.isInterface()) {
pf.addInterface(dependencyType);
}
// 通过ProxyFactory生成代理对象
return pf.getProxy(beanFactory.getBeanClassLoader());
}
稍微记一下这个类：TargetSource[目标源]，在Spring AOP体系中占有非常重要的地位，它是被代理对象的抽象表示，可以包含真实的被代理对象本身[直接包含]，也可以包含"能够获取被代理对象的代码"[间接包含]，因此称为目标"源"而非目标，隐喻着可以通过某种手段获取被代理对象，且多次获取的被代理对象可能是同一个，也可能不是同一个，这对于上层应用而言是无感知的，由TargetSource行为所决定
到此处，我们得到一个结论：通过在构造器参数中标识@Lazy注解，Spring 生成并返回了一个代理对象，因此给Foo注入的Bar并非真实对象而是其代理
行文到此处，我们的问题已经解决：Foo依赖的Bar由于标识了@Lazy注解，因此注入的是一个代理对象，顺利完成了Foo实例的构造；而Bar依赖的Foo是直注入完整的Foo对象本身。因此，这里通过@Lazy巧妙地避开了循环依赖的发生
WX20200329-162547@2x.png
虽然构造器注入的循环依赖解决了，程序也能正常启动，但是程序执行的时候是不是我们想要的效果呢？也即是说，Foo中的代理对象Bar如何与真实的Bar对象关联起来的呢？
- 在Bar中任意添加一个方法，通过Foo去用
@Component
public class Foo {
private Bar bar;
public Foo(@Lazy Bar bar) {
this.bar = bar;
}
public void bar() {
bar.bar();
}
}
@Component
public class Bar {
private Foo foo;
public Bar(Foo foo) {
this.foo = foo;
}
public void bar() { }
}
- 执行Foo#bar方法时，会执行Bar#bar方法，由于Bar是个代理对象，必然先进入代理逻辑。由于Bar并非接口，不能通过JDK代理，因此是通过Cglib代理，如下示
// org.springframework.aop.framework.CglibAopProxy.DynamicAdvisedInterceptor#intercept
private static class DynamicAdvisedInterceptor implements MethodInterceptor, Serializable {
private final AdvisedSupport advised;
public DynamicAdvisedInterceptor(AdvisedSupport advised) {
this.advised = advised;
}
@Override
@Nullable
public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
Object oldProxy = null;
boolean setProxyContext = false;
Object target = null;
// 上文提到的TargetSource
TargetSource targetSource = this.advised.getTargetSource();
// Get as late as possible to minimize the time we "own" the target, in case it comes from a pool...[可以仔细品品该注释]
// 通过TargetSource来获取被代理的对象target
target = targetSource.getTarget();
// ...(省略)
if (chain.isEmpty() && Modifier.isPublic(method.getModifiers())) {
Object[] argsToUse = AopProxyUtils.adaptArgumentsIfNecessary(method, args);
// 通过反射调用被代理对象的方法
retVal = methodProxy.invoke(target, argsToUse);
}
// ...(省略)
}
}
代码中，通过TargetSource#getTarget来获取被代理的对象target，然后通过反射完成被代理对象的方法调用
我们回过头来看此处的TargetSource是什么，在上面的buildLazyResolutionProxy方法中，构造了TargetSource，把省略的代码展开：
TargetSource ts = new TargetSource() {
@Override
public Class<?> getTargetClass() {
// Bar.class
return descriptor.getDependencyType();
}
@Override
public boolean isStatic() {
return false;
}
@Override
public Object getTarget() {
// 通过beanFactory去真正解析依赖(Bar)，将Spring IoC里真实的Bar返回
Object target = beanFactory.doResolveDependency(descriptor, beanName, null, null);
if (target == null) {
Class<?> type = getTargetClass();
if (Map.class == type) {
return Collections.emptyMap();
}
else if (List.class == type) {
return Collections.emptyList();
}
else if (Set.class == type || Collection.class == type) {
return Collections.emptySet();
}
throw new NoSuchBeanDefinitionException(descriptor.getResolvableType(),
"Optional dependency not present for lazy injection point");
}
return target;
}
@Override
public void releaseTarget(Object target) {
}
};
最关键的一行代码是Object target = beanFactory.doResolveDependency(descriptor, beanName, null, null);，它的作用是通过beanFactory去真正解析依赖(Bar)，将Spring IoC里真实的Bar返回，如此，就拿到了真正的Bar对象
此处我们可以得到一个结论：代理对象Bar与真实的Bar对象，是通过TargetSouce关联起来的，每次执行被代理对象的方法时，都会先通过TargetSouce去拿到真实的对象[DefaultListableBeanFactory#doResolveDependency]，然后通过反射进行调用
结论
Spring构造器注入循环依赖的解决方案是@Lazy，其基本思路是：对于强依赖的对象，一开始并不注入对象本身，而是注入其代理对象，以便顺利完成实例的构造，形成一个完成的对象，这样与其它应用层对象就不会形成互相依赖的关系；当需要调用真实对象的方法时，通过TargetSouce去拿到真实的对象[DefaultListableBeanFactory#doResolveDependency]，然后通过反射完成调用
题外话
Setter注入或者Field注入的循环依赖解决方案，网上有诸多的文章都说是依靠"三级缓存"，其实笔者一直不赞同这种说法，原因是"三级缓存"概念本身在现有语义下容易让初学者产生误解，让人联想成多级缓存，且缓存之间有层次递进的关系，比如CPU多级缓存的概念(L1 Cache，L2 Cache，L3 Cache)，以及服务中使用多级缓存(Local Cache，Remote Cache)。如果研究相关源码可以知道，三个Map(earlySingletonObjects、singletonFactories、singletonObjects)实际上并没有层次递进的关系，同一个对象同一时刻只会存在一个Map当中，如果想将对象放入另一个Map，需要将对象从其余的Map中移除，因此是一种互斥的关系而非层次递进的关系，不符合常规理解下对"多级"缓存的认知，这也是本文前言称为三个Map而非三级缓存的缘由
概念不重要，重要的是理解Spring在这个过程中做了哪些事，但如果因为概念本身给人带来误解，就是技术人的罪过了
说个段子
纲："我们家狗的名字叫猫咪"
谦："那您家那猫呢？"
纲："叫兔子"
谦："那兔子呢？"
纲："叫儿子"
谦："那儿子呢？"
纲："儿子叫于谦"
导读：
AutowireCapableBeanFactory探密(1)——为第三方框架赋能
AutowireCapableBeanFactory探密(2)——传统装配模式与现代注解驱动注入方式
AutowireCapableBeanFactory探密(3)——依赖解析
网友评论