Spring构造器注入循环依赖的解决方案及原理探索

前言

我们都知道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

1. 构造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);
}

2. 接着，通过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);
	// ... (省略)
}

3. 接着，便来到了熟悉的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;

}

4. 接着，先判断依赖项是否含有@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巧妙地避开了循环依赖的发生

虽然构造器注入的循环依赖解决了，程序也能正常启动，但是程序执行的时候是不是我们想要的效果呢？也即是说，Foo中的代理对象Bar如何与真实的Bar对象关联起来的呢？

5. 在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() { }
}

6. 执行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对象，是通过TargetSource关联起来的，每次执行被代理对象的方法时，都会先通过TargetSource去拿到真实的对象[DefaultListableBeanFactory#doResolveDependency]，然后通过反射进行调用

结论

Spring构造器注入循环依赖的解决方案是@Lazy，其基本思路是：对于强依赖的对象，一开始并不注入对象本身，而是注入其代理对象，以便顺利完成实例的构造，形成一个完整的对象，这样与其它应用层对象就不会形成互相依赖的关系；当需要调用真实对象的方法时，通过TargetSource去拿到真实的对象[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)——依赖解析