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

構造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巧妙地避開了循環依賴的發生

雖然構造器注入的循環依賴解決了，程序也能正常啓動，但是程序執行的時候是不是我們想要的效果呢？也即是說，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)——依賴解析

Spring構造器注入循環依賴的解決方案及原理探索

前言

案例

解決方案

原理分析

結論

題外話

Java System#exit 無法退出程序的問題探索

Spring Boot + Apollo 動態修改日誌級別

Spring構造器注入循環依賴的解決方案及原理探索

Mybatis優雅存取json字段的解決方案 - TypeHandler (一)

AutowireCapableBeanFactory探密(2)——傳統裝配模式與現代註解驅動注入方式

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結