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);
}
  1. 接着,通過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);
	// ... (省略)
}
  1. 接着,便來到了熟悉的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;

}
  1. 接着,先判斷依賴項是否含有@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對象關聯起來的呢?

  1. 在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() { }
}
  1. 執行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)——依賴解析

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章