前言
我們都知道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)——爲第三方框架賦能