你知道怎么用Spring的三級緩存解決循環(huán)依賴嗎
1. 前言
循環(huán)依賴:就是N個類循環(huán)(嵌套)引用。
通俗的講就是N個Bean互相引用對方,最終形成閉環(huán)。用一副經(jīng)典的圖示可以表示成這樣(A、B、C都代表對象,虛線代表引用關系):

- 其實可以N=1,也就是極限情況的循環(huán)依賴:
自己依賴自己 - 這里指的循環(huán)引用不是方法之間的循環(huán)調用,而是對象的相互依賴關系。(方法之間循環(huán)調用若有出口也是能夠正常work的
2. Spring Bean的循環(huán)依賴
談到Spring Bean的循環(huán)依賴,有的小伙伴可能比較陌生,畢竟開發(fā)過程中好像對循環(huán)依賴這個概念無感知。其實不然,你有這種錯覺,權是因為你工作在Spring的襁褓中,從而讓你“高枕無憂”~
我十分堅信,小伙伴們在平時業(yè)務開發(fā)中一定一定寫過如下結構的代碼:
@Service
public class AServiceImpl implements AService {
@Autowired
private BService bService;
...
}
@Service
public class BServiceImpl implements BService {
@Autowired
private AService aService;
...
}這其實就是Spring環(huán)境下典型的循環(huán)依賴場景。但是很顯然,這種循環(huán)依賴場景,Spring已經(jīng)完美的幫我們解決和規(guī)避了問題。所以即使平時我們這樣循環(huán)引用,也能夠整成進行我們的coding之旅~
3. Spring中三大循環(huán)依賴場景演示
在Spring環(huán)境中,因為我們的Bean的實例化、初始化都是交給了容器,因此它的循環(huán)依賴主要表現(xiàn)為下面三種場景。為了方便演示,我準備了如下兩個類:

3.1 構造器注入循環(huán)依賴
@Service
public class A {
public A(B b) {
}
}
@Service
public class B {
public B(A a) {
}
}結果:項目啟動失敗拋出異常BeanCurrentlyInCreationException
Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'a': Requested bean is currently in creation: Is there an unresolvable circular reference? at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.beforeSingletonCreation(DefaultSingletonBeanRegistry.java:339) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:215) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:318) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
構造器注入構成的循環(huán)依賴,此種循環(huán)依賴方式是無法解決的,只能拋出
BeanCurrentlyInCreationException異常表示循環(huán)依賴。這也是構造器注入的最大劣勢(它有很多獨特的優(yōu)勢,請小伙伴自行發(fā)掘)
根本原因:Spring解決循環(huán)依賴依靠的是Bean的“中間態(tài)”這個概念,而這個中間態(tài)指的是已經(jīng)實例化,但還沒初始化的狀態(tài)。而構造器是完成實例化的東東,所以構造器的循環(huán)依賴無法解決~~~
3.2 singleton模式field屬性注入循環(huán)依賴
這種方式是我們最最最最為常用的依賴注入方式(所以猜都能猜到它肯定不會有問題啦):
@Service
public class A {
@Autowired
private B b;
}
@Service
public class B {
@Autowired
private A a;
}結果:項目啟動成功,能夠正常work
備注:setter方法注入方式因為原理和字段注入方式類似,此處不多加演示
3.3 prototype模式field屬性注入循環(huán)依賴
prototype在平時使用情況較少,但是也并不是不會使用到,因此此種方式也需要引起重視。
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@Service
public class A {
@Autowired
private B b;
}
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
@Service
public class B {
@Autowired
private A a;
}結果:需要注意的是本例中啟動時是不會報錯的(因為非單例Bean默認不會初始化,而是使用時才會初始化),所以很簡單咱們只需要手動getBean()或者在一個單例Bean內@Autowired一下它即可
// 在單例Bean內注入
@Autowired
private A a;這樣子啟動就報錯:
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'mytest.TestSpringBean': Unsatisfied dependency expressed through field 'a'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'a': Unsatisfied dependency expressed through field 'b'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'b': Unsatisfied dependency expressed through field 'a'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'a': Requested bean is currently in creation: Is there an unresolvable circular reference? at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:596) at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:90) at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:374)
如何解決???
可能有的小伙伴看到網(wǎng)上有說使用@Lazy注解解決:
@Lazy
@Autowired
private A a;此處負責任的告訴你這樣是解決不了問題的(可能會掩蓋問題),@Lazy只是延遲初始化而已,當你真正使用到它(初始化)的時候,依舊會報如上異常。
對于Spring循環(huán)依賴的情況總結如下:
不能解決的情況:
構造器注入循環(huán)依賴
prototype模式field屬性注入循環(huán)依賴
能解決的情況:
singleton模式field屬性注入(setter方法注入)循環(huán)依賴
4. Spring解決循環(huán)依賴的原理分析
在這之前需要明白java中所謂的引用傳遞和值傳遞的區(qū)別。
說明:看到這句話可能有小伙伴就想噴我了。java中明明都是傳遞啊,這是我初學java時背了100遍的面試題,怎么可能有錯???
這就是我做這個申明的必要性:伙計,你的說法是正確的,java中只有值傳遞。但是本文借用引用傳遞來輔助講解,希望小伙伴明白我想表達的意思~
Spring的循環(huán)依賴的理論依據(jù)基于Java的引用傳遞,當獲得對象的引用時,對象的屬性是可以延后設置的。(但是構造器必須是在獲取引用之前,畢竟你的引用是靠構造器給你生成的,兒子能先于爹出生?哈哈)
4.1 Spring創(chuàng)建Bean的流程
首先需要了解是Spring它創(chuàng)建Bean的流程,我把它的大致調用棧繪圖如下:

對Bean的創(chuàng)建最為核心三個方法解釋如下:
createBeanInstance:例化,其實也就是調用對象的構造方法實例化對象populateBean:填充屬性,這一步主要是對bean的依賴屬性進行注入(@Autowired)initializeBean:回到一些形如initMethod、InitializingBean等方法
從對單例Bean的初始化可以看出,循環(huán)依賴主要發(fā)生在第二步(populateBean),也就是field屬性注入的處理。
4.2 Spring容器的“三級緩存”
在Spring容器的整個聲明周期中,單例Bean有且僅有一個對象。這很容易讓人想到可以用緩存來加速訪問。
從源碼中也可以看出Spring大量運用了Cache的手段,在循環(huán)依賴問題的解決過程中甚至不惜使用了“三級緩存”,這也便是它設計的精妙之處~
三級緩存其實它更像是Spring容器工廠的內的術語,采用三級緩存模式來解決循環(huán)依賴問題,這三級緩存分別指:
public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
...
// 從上至下 分表代表這“三級緩存”
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256); //一級緩存
private final Map<String, Object> earlySingletonObjects = new HashMap<>(16); // 二級緩存
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16); // 三級緩存
...
/** Names of beans that are currently in creation. */
// 這個緩存也十分重要:它表示bean創(chuàng)建過程中都會在里面呆著~
// 它在Bean開始創(chuàng)建時放值,創(chuàng)建完成時會將其移出~
private final Set<String> singletonsCurrentlyInCreation = Collections.newSetFromMap(new ConcurrentHashMap<>(16));
/** Names of beans that have already been created at least once. */
// 當這個Bean被創(chuàng)建完成后,會標記為這個 注意:這里是set集合 不會重復
// 至少被創(chuàng)建了一次的 都會放進這里~~~~
private final Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256));
}注:AbstractBeanFactory繼承自DefaultSingletonBeanRegistry
singletonObjects:用于存放完全初始化好的 bean,從該緩存中取出的 bean 可以直接使用earlySingletonObjects:提前曝光的單例對象的cache,存放原始的 bean 對象(尚未填充屬性),用于解決循環(huán)依賴singletonFactories:單例對象工廠的cache,存放 bean 工廠對象,用于解決循環(huán)依賴
獲取單例Bean的源碼如下:
public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
...
@Override
@Nullable
public Object getSingleton(String beanName) {
return getSingleton(beanName, true);
}
@Nullable
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
synchronized (this.singletonObjects) {
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null && allowEarlyReference) {
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
singletonObject = singletonFactory.getObject();
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
return singletonObject;
}
...
public boolean isSingletonCurrentlyInCreation(String beanName) {
return this.singletonsCurrentlyInCreation.contains(beanName);
}
protected boolean isActuallyInCreation(String beanName) {
return isSingletonCurrentlyInCreation(beanName);
}
...
}1.先從一級緩存singletonObjects中去獲取。(如果獲取到就直接return)
2.如果獲取不到或者對象正在創(chuàng)建中(isSingletonCurrentlyInCreation()),那就再從二級緩存earlySingletonObjects中獲取。(如果獲取到就直接return)
3.如果還是獲取不到,且允許singletonFactories(allowEarlyReference=true)通過getObject()獲取。就從三級緩存singletonFactory.getObject()獲取。(如果獲取到了就從singletonFactories中移除,并且放進earlySingletonObjects。其實也就是從三級緩存移動(是剪切、不是復制哦~)到了二級緩存)
加入
singletonFactories三級緩存的前提是執(zhí)行了構造器,所以構造器的循環(huán)依賴沒法解決
getSingleton()從緩存里獲取單例對象步驟分析可知,Spring解決循環(huán)依賴的訣竅:就在于singletonFactories這個三級緩存。這個Cache里面都是ObjectFactory,它是解決問題的關鍵。
// 它可以將創(chuàng)建對象的步驟封裝到ObjectFactory中 交給自定義的Scope來選擇是否需要創(chuàng)建對象來靈活的實現(xiàn)scope。 具體參見Scope接口
@FunctionalInterface
public interface ObjectFactory<T> {
T getObject() throws BeansException;
}經(jīng)過ObjectFactory.getObject()后,此時放進了二級緩存
earlySingletonObjects內。這個時候對象已經(jīng)實例化了,雖然還不完美,但是對象的引用已經(jīng)可以被其它引用了。
此處說一下二級緩存earlySingletonObjects它里面的數(shù)據(jù)什么時候添加什么移除???
添加:向里面添加數(shù)據(jù)只有一個地方,就是上面說的getSingleton()里從三級緩存里挪過來
移除:addSingleton、addSingletonFactory、removeSingleton從語義中可以看出添加單例、添加單例工廠ObjectFactory的時候都會刪除二級緩存里面對應的緩存值,是互斥的。
4.3 源碼解析
Spring容器會將每一個正在創(chuàng)建的Bean 標識符放在一個“當前創(chuàng)建Bean池”中,Bean標識符在創(chuàng)建過程中將一直保持在這個池中,而對于創(chuàng)建完畢的Bean將從當前創(chuàng)建Bean池中清除掉。
這個“當前創(chuàng)建Bean池”指的是上面提到的singletonsCurrentlyInCreation那個集合。
public abstract class AbstractBeanFactory extends FactoryBeanRegistrySupport implements ConfigurableBeanFactory {
...
protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType, @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {
...
// Eagerly check singleton cache for manually registered singletons.
// 先去獲取一次,如果不為null,此處就會走緩存了~~
Object sharedInstance = getSingleton(beanName);
...
// 如果不是只檢查類型,那就標記這個Bean被創(chuàng)建了~~添加到緩存里 也就是所謂的 當前創(chuàng)建Bean池
if (!typeCheckOnly) {
markBeanAsCreated(beanName);
}
...
// Create bean instance.
if (mbd.isSingleton()) {
// 這個getSingleton方法不是SingletonBeanRegistry的接口方法 屬于實現(xiàn)類DefaultSingletonBeanRegistry的一個public重載方法~~~
// 它的特點是在執(zhí)行singletonFactory.getObject();前后會執(zhí)行beforeSingletonCreation(beanName);和afterSingletonCreation(beanName);
// 也就是保證這個Bean在創(chuàng)建過程中,放入正在創(chuàng)建的緩存池里 可以看到它實際創(chuàng)建bean調用的是我們的createBean方法~~~~
sharedInstance = getSingleton(beanName, () -> {
try {
return createBean(beanName, mbd, args);
} catch (BeansException ex) {
destroySingleton(beanName);
throw ex;
}
});
bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}
}
...
}
// 抽象方法createBean所在地 這個接口方法是屬于抽象父類AbstractBeanFactory的 實現(xiàn)在這個抽象類里
public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory implements AutowireCapableBeanFactory {
...
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args) throws BeanCreationException {
...
// 創(chuàng)建Bean對象,并且將對象包裹在BeanWrapper 中
instanceWrapper = createBeanInstance(beanName, mbd, args);
// 再從Wrapper中把Bean原始對象(非代理~~~) 這個時候這個Bean就有地址值了,就能被引用了~~~
// 注意:此處是原始對象,這點非常的重要
final Object bean = instanceWrapper.getWrappedInstance();
...
// earlySingletonExposure 用于表示是否”提前暴露“原始對象的引用,用于解決循環(huán)依賴。
// 對于單例Bean,該變量一般為 true 但你也可以通過屬性allowCircularReferences = false來關閉循環(huán)引用
// isSingletonCurrentlyInCreation(beanName) 表示當前bean必須在創(chuàng)建中才行
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
if (logger.isTraceEnabled()) {
logger.trace("Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references");
}
// 上面講過調用此方法放進一個ObjectFactory,二級緩存會對應刪除的
// getEarlyBeanReference的作用:調用SmartInstantiationAwareBeanPostProcessor.getEarlyBeanReference()這個方法 否則啥都不做
// 也就是給調用者個機會,自己去實現(xiàn)暴露這個bean的應用的邏輯~~~
// 比如在getEarlyBeanReference()里可以實現(xiàn)AOP的邏輯~~~ 參考自動代理創(chuàng)建器AbstractAutoProxyCreator 實現(xiàn)了這個方法來創(chuàng)建代理對象
// 若不需要執(zhí)行AOP的邏輯,直接返回Bean
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}
Object exposedObject = bean; //exposedObject 是最終返回的對象
...
// 填充屬于,解決@Autowired依賴~
populateBean(beanName, mbd, instanceWrapper);
// 執(zhí)行初始化回調方法們~~~
exposedObject = initializeBean(beanName, exposedObject, mbd);
// earlySingletonExposure:如果你的bean允許被早期暴露出去 也就是說可以被循環(huán)引用 那這里就會進行檢查
// 此段代碼非常重要~~~~~但大多數(shù)人都忽略了它
if (earlySingletonExposure) {
// 此時一級緩存肯定還沒數(shù)據(jù),但是呢此時候二級緩存earlySingletonObjects也沒數(shù)據(jù)
//注意,注意:第二參數(shù)為false 表示不會再去三級緩存里查了~~~
// 此處非常巧妙的一點:::因為上面各式各樣的實例化、初始化的后置處理器都執(zhí)行了,如果你在上面執(zhí)行了這一句
// ((ConfigurableListableBeanFactory)this.beanFactory).registerSingleton(beanName, bean);
// 那么此處得到的earlySingletonReference 的引用最終會是你手動放進去的Bean最終返回,完美的實現(xiàn)了"偷天換日" 特別適合中間件的設計
// 我們知道,執(zhí)行完此doCreateBean后執(zhí)行addSingleton() 其實就是把自己再添加一次 **再一次強調,完美實現(xiàn)偷天換日**
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
// 這個意思是如果經(jīng)過了initializeBean()后,exposedObject還是木有變,那就可以大膽放心的返回了
// initializeBean會調用后置處理器,這個時候可以生成一個代理對象,那這個時候它哥倆就不會相等了 走else去判斷吧
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
// allowRawInjectionDespiteWrapping這個值默認是false
// hasDependentBean:若它有依賴的bean 那就需要繼續(xù)校驗了~~~(若沒有依賴的 就放過它~)
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
// 拿到它所依賴的Bean們~~~~ 下面會遍歷一個一個的去看~~
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
// 一個個檢查它所以Bean
// removeSingletonIfCreatedForTypeCheckOnly這個放見下面 在AbstractBeanFactory里面
// 簡單的說,它如果判斷到該dependentBean并沒有在創(chuàng)建中的了的情況下,那就把它從所有緩存中移除~~~ 并且返回true
// 否則(比如確實在創(chuàng)建中) 那就返回false 進入我們的if里面~ 表示所謂的真正依賴
//(解釋:就是真的需要依賴它先實例化,才能實例化自己的依賴)
for (String dependentBean : dependentBeans) {
if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
actualDependentBeans.add(dependentBean);
}
}
// 若存在真正依賴,那就報錯(不要等到內存移除你才報錯,那是非常不友好的)
// 這個異常是BeanCurrentlyInCreationException,報錯日志也稍微留意一下,方便定位錯誤~~~~
if (!actualDependentBeans.isEmpty()) {
throw new BeanCurrentlyInCreationException(beanName,
"Bean with name '" + beanName + "' has been injected into other beans [" +
StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
"] in its raw version as part of a circular reference, but has eventually been " +
"wrapped. This means that said other beans do not use the final version of the " +
"bean. This is often the result of over-eager type matching - consider using " +
"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
}
}
}
}
return exposedObject;
}
// 雖然是remove方法 但是它的返回值也非常重要
// 該方法唯一調用的地方就是循環(huán)依賴的最后檢查處~~~~~
protected boolean removeSingletonIfCreatedForTypeCheckOnly(String beanName) {
// 如果這個bean不在創(chuàng)建中 比如是ForTypeCheckOnly的 那就移除掉
if (!this.alreadyCreated.contains(beanName)) {
removeSingleton(beanName);
return true;
}
else {
return false;
}
}
}這里舉例:例如是field屬性依賴注入,在populateBean時它就會先去完成它所依賴注入的那個bean的實例化、初始化過程,最終返回到本流程繼續(xù)處理,因此Spring這樣處理是不存在任何問題的。
這里有個小細節(jié):
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}這一句如果exposedObject == bean表示最終返回的對象就是原始對象,說明在populateBean和initializeBean沒對他代理過,那就啥話都不說了exposedObject = earlySingletonReference,最終把二級緩存里的引用返回即可~
4.4 流程總結
此處以如上的A、B類的互相依賴注入為例,在這里表達出關鍵代碼的走勢:
1. 入口處即是實例化、初始化A這個單例Bean。AbstractBeanFactory.doGetBean("a")
protected <T> T doGetBean(...){
...
// 標記beanName a是已經(jīng)創(chuàng)建過至少一次的~~~ 它會一直存留在緩存里不會被移除(除非拋出了異常)
// 參見緩存Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256))
if (!typeCheckOnly) {
markBeanAsCreated(beanName);
}
// 此時a不存在任何一級緩存中,且不是在創(chuàng)建中 所以此處返回null
// 此處若不為null,然后從緩存里拿就可以了(主要處理FactoryBean和BeanFactory情況吧)
Object beanInstance = getSingleton(beanName, false);
...
// 這個getSingleton方法非常關鍵。
//1、標注a正在創(chuàng)建中~
//2、調用singletonObject = singletonFactory.getObject();(實際上調用的是createBean()方法) 因此這一步最為關鍵
//3、此時實例已經(jīng)創(chuàng)建完成 會把a移除整整創(chuàng)建的緩存中
//4、執(zhí)行addSingleton()添加進去。(備注:注冊bean的接口方法為registerSingleton,它依賴于addSingleton方法)
sharedInstance = getSingleton(beanName, () -> { ... return createBean(beanName, mbd, args); });
}protected <T> T doGetBean(...){
...
// 標記beanName a是已經(jīng)創(chuàng)建過至少一次的~~~ 它會一直存留在緩存里不會被移除(除非拋出了異常)
// 參見緩存Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256))
if (!typeCheckOnly) {
markBeanAsCreated(beanName);
}
// 此時a不存在任何一級緩存中,且不是在創(chuàng)建中 所以此處返回null
// 此處若不為null,然后從緩存里拿就可以了(主要處理FactoryBean和BeanFactory情況吧)
Object beanInstance = getSingleton(beanName, false);
...
// 這個getSingleton方法非常關鍵。
//1、標注a正在創(chuàng)建中~
//2、調用singletonObject = singletonFactory.getObject();(實際上調用的是createBean()方法) 因此這一步最為關鍵
//3、此時實例已經(jīng)創(chuàng)建完成 會把a移除整整創(chuàng)建的緩存中
//4、執(zhí)行addSingleton()添加進去。(備注:注冊bean的接口方法為registerSingleton,它依賴于addSingleton方法)
sharedInstance = getSingleton(beanName, () -> { ... return createBean(beanName, mbd, args); });
}2. 下面進入到最為復雜的AbstractAutowireCapableBeanFactory.createBean/doCreateBean()環(huán)節(jié),創(chuàng)建A的實例
protected Object doCreateBean(){
...
// 使用構造器/工廠方法 instanceWrapper是一個BeanWrapper
instanceWrapper = createBeanInstance(beanName, mbd, args);
// 此處bean為"原始Bean" 也就是這里的A實例對象:A@1234
final Object bean = instanceWrapper.getWrappedInstance();
...
// 是否要提前暴露(允許循環(huán)依賴) 現(xiàn)在此處A是被允許的
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
// 允許暴露,就把A綁定在ObjectFactory上,注冊到三級緩存`singletonFactories`里面去保存著
// Tips:這里后置處理器的getEarlyBeanReference方法會被促發(fā),自動代理創(chuàng)建器在此處創(chuàng)建代理對象(注意執(zhí)行時機 為執(zhí)行三級緩存的時候)
if (earlySingletonExposure) {
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}
...
// exposedObject 為最終返回的對象,此處為原始對象bean也就是A@1234,下面會有用處
Object exposedObject = bean;
// 給A@1234屬性完成賦值,@Autowired在此處起作用~
// 因此此處會調用getBean("b"),so 會重復上面步驟創(chuàng)建B類的實例
// 此處我們假設B已經(jīng)創(chuàng)建好了 為B@5678
// 需要注意的是在populateBean("b")的時候依賴有beanA,所以此時候調用getBean("a")最終會調用getSingleton("a"),
//此時候上面說到的getEarlyBeanReference方法就會被執(zhí)行。這也解釋為何我們@Autowired是個代理對象,而不是普通對象的根本原因
populateBean(beanName, mbd, instanceWrapper);
// 實例化。這里會執(zhí)行后置處理器BeanPostProcessor的兩個方法
// 此處注意:postProcessAfterInitialization()是有可能返回一個代理對象的,這樣exposedObject 就不再是原始對象了 特備注意哦~~~
// 比如處理@Aysnc的AsyncAnnotationBeanPostProcessor它就是在這個時間里生成代理對象的(有坑,請小心使用@Aysnc)
exposedObject = initializeBean(beanName, exposedObject, mbd);
... // 至此,相當于A@1234已經(jīng)實例化完成、初始化完成(屬性也全部賦值了~)
// 這一步我把它理解為校驗:校驗:校驗是否有循環(huán)引用問題~~~~~
if (earlySingletonExposure) {
// 注意此處第二個參數(shù)傳的false,表示不去三級緩存里singletonFactories再去調用一次getObject()方法了~~~
// 上面建講到了由于B在初始化的時候,會觸發(fā)A的ObjectFactory.getObject() 所以a此處已經(jīng)在二級緩存earlySingletonObjects里了
// 因此此處返回A的實例:A@1234
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
// 這個等式表示,exposedObject若沒有再被代理過,這里就是相等的
// 顯然此處我們的a對象的exposedObject它是沒有被代理過的 所以if會進去~
// 這種情況至此,就全部結束了~~~
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
// 繼續(xù)以A為例,比如方法標注了@Aysnc注解,exposedObject此時候就是一個代理對象,因此就會進到這里來
//hasDependentBean(beanName)是肯定為true,因為getDependentBeans(beanName)得到的是["b"]這個依賴
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
// A@1234依賴的是["b"],所以此處去檢查b
// 如果最終存在實際依賴的bean:actualDependentBeans不為空 那就拋出異常 證明循環(huán)引用了~
for (String dependentBean : dependentBeans) {
// 這個判斷原則是:如果此時候b并還沒有創(chuàng)建好,this.alreadyCreated.contains(beanName)=true表示此bean已經(jīng)被創(chuàng)建過,就返回false
// 若該bean沒有在alreadyCreated緩存里,就是說沒被創(chuàng)建過(其實只有CreatedForTypeCheckOnly才會是此倉庫)
if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
actualDependentBeans.add(dependentBean);
}
}
if (!actualDependentBeans.isEmpty()) {
throw new BeanCurrentlyInCreationException(beanName,
"Bean with name '" + beanName + "' has been injected into other beans [" +
StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
"] in its raw version as part of a circular reference, but has eventually been " +
"wrapped. This means that said other beans do not use the final version of the " +
"bean. This is often the result of over-eager type matching - consider using " +
"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
}
}
}
}
}由于關鍵代碼部分的步驟不太好拆分,為了更具象表達,那么使用下面一副圖示幫助小伙伴們理解:

5. 總結
依舊以上面A、B類使用屬性field注入循環(huán)依賴的例子為例,對整個流程做文字步驟總結如下:
- 使用context.getBean(A.class),旨在獲取容器內的單例A(若A不存在,就會走A這個Bean的創(chuàng)建流程),顯然初次獲取A是不存在的,因此走A的創(chuàng)建之路~
- 實例化A(注意此處僅僅是實例化),并將它放進緩存(此時A已經(jīng)實例化完成,已經(jīng)可以被引用了)
- 初始化A:@Autowired依賴注入B(此時需要去容器內獲取B)
- 為了完成依賴注入B,會通過getBean(B)去容器內找B。但此時B在容器內不存在,就走向B的創(chuàng)建之路~
- 實例化B,并將其放入緩存。(此時B也能夠被引用了)
- 初始化B,@Autowired依賴注入A(此時需要去容器內獲取A)
- 此處重要:初始化B時會調用getBean(A)去容器內找到A,上面我們已經(jīng)說過了此時候因為A已經(jīng)實例化完成了并且放進了緩存里,所以這個時候去看緩存里是已經(jīng)存在A的引用了的,所以getBean(A)能夠正常返回
- B初始化成功(此時已經(jīng)注入A成功了,已成功持有A的引用了),return(注意此處return相當于是返回最上面的getBean(B)這句代碼,回到了初始化A的流程中~)。
- 因為B實例已經(jīng)成功返回了,因此最終A也初始化成功
- 到此,B持有的已經(jīng)是初始化完成的A,A持有的也是初始化完成的B,完美~
站的角度高一點,宏觀上看Spring處理循環(huán)依賴的整個流程就是如此。希望這個宏觀層面的總結能更加有助于小伙伴們對Spring解決循環(huán)依賴的原理的了解,同時也順便能解釋為何構造器循環(huán)依賴就不好使的原因。
本篇文章就到這里了,希望能夠給你帶來幫助,也希望您能夠多多關注腳本之家的更多內容!
相關文章
springboot hazelcast緩存中間件的實例代碼
這篇文章主要介紹了springboot hazelcast緩存中間件的實例代碼,非常不錯,具有一定的參考借鑒價值,需要的朋友可以參考下2018-08-08
SpringBoot AOP AspectJ切面技術介紹與實現(xiàn)方式
這篇文章主要介紹了Springboot如何使用Aspectj實現(xiàn)AOP面向切面編程,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-10-10
MyBatis-Flex實現(xiàn)多表聯(lián)查(自動映射)
我們可以輕松的使用 Mybaits-Flex 鏈接任何數(shù)據(jù)庫,本文主要介紹了MyBatis-Flex實現(xiàn)多表聯(lián)查(自動映射),具有一定的參考價值,感興趣的可以了解一下2024-06-06
spring中BeanUtils.copyProperties的使用(深拷貝,淺拷貝)
本文主要介紹了spring中BeanUtils.copyProperties的使用(深拷貝,淺拷貝),文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2023-05-05

