前言

在使用spring框架的日常開(kāi)發(fā)中，bean之間的循環(huán)依賴(lài)太頻繁了，spring已經(jīng)幫我們?nèi)ソ鉀Q循環(huán)依賴(lài)問(wèn)題，對(duì)我們開(kāi)發(fā)者來(lái)說(shuō)是無(wú)感知的，下面具體分析一下spring是如何解決bean之間循環(huán)依賴(lài)，為什么要使用到三級(jí)緩存，而不是二級(jí)緩存

bean生命周期

首先大家需要了解一下bean在spring中的生命周期，bean在spring的加載流程，才能夠更加清晰知道spring是如何解決循環(huán)依賴(lài)的

我們?cè)趕pring的BeanFactory工廠(chǎng)列舉了很多接口，代表著bean的生命周期，我們主要記住的是我圈紅線(xiàn)圈出來(lái)的接口, 再結(jié)合spring的源碼來(lái)看這些接口主要是在哪里調(diào)用的

AbstractAutowireCapableBeanFactory類(lèi)的doCreateBean方法是創(chuàng)建bean的開(kāi)始，我們可以看到首先需要實(shí)例化這個(gè)bean，也就是在堆中開(kāi)辟一塊內(nèi)存空間給這個(gè)對(duì)象，createBeanInstance方法里面邏輯大概就是采用反射生成實(shí)例對(duì)象，進(jìn)行到這里表示對(duì)象還并未進(jìn)行屬性的填充，也就是@Autowired注解的屬性還未得到注入

我們可以看到第二步就是填充bean的成員屬性，populateBean方法里面的邏輯大致就是對(duì)使用到了注入屬性的注解就會(huì)進(jìn)行注入，如果在注入的過(guò)程發(fā)現(xiàn)注入的對(duì)象還沒(méi)生成，則會(huì)跑去生產(chǎn)要注入的對(duì)象，第三步就是調(diào)用initializeBean方法初始化bean，也就是調(diào)用我們上述所提到的接口

可以看到initializeBean方法中，首先調(diào)用的是使用的Aware接口的方法，我們具體看一下invokeAwareMethods方法中會(huì)調(diào)用Aware接口的那些方法

我們可以知道如果我們實(shí)現(xiàn)了BeanNameAware，BeanClassLoaderAware，BeanFactoryAware三個(gè)Aware接口的話(huà)，會(huì)依次調(diào)用setBeanName(), setBeanClassLoader(), setBeanFactory()方法，再看applyBeanPostProcessorsBeforeInitialization源碼

發(fā)現(xiàn)會(huì)如果有類(lèi)實(shí)現(xiàn)了BeanPostProcessor接口，就會(huì)執(zhí)行postProcessBeforeInitialization方法，這里需要注意的是：如果多個(gè)類(lèi)實(shí)現(xiàn)BeanPostProcessor接口，那么多個(gè)實(shí)現(xiàn)類(lèi)都會(huì)執(zhí)行postProcessBeforeInitialization方法，可以看到是for循環(huán)依次執(zhí)行的，還有一個(gè)注意的點(diǎn)就是如果加載A類(lèi)到spring容器中，A類(lèi)也重寫(xiě)了BeanPostProcessor接口的postProcessBeforeInitialization方法，這時(shí)要注意A類(lèi)的postProcessBeforeInitialization方法并不會(huì)得到執(zhí)行，因?yàn)锳類(lèi)還未加載完成，還未完全放到spring的singletonObjects一級(jí)緩存中。

再看一個(gè)注意的點(diǎn)

可以看到ApplicationContextAwareProcessor也實(shí)現(xiàn)了BeanPostProcessor接口，重寫(xiě)了postProcessBeforeInitialization方法，方法里面并調(diào)用了invokeAwareInterfaces方法，而invokeAwareInterfaces方法也寫(xiě)著如果實(shí)現(xiàn)了眾多的Aware接口，則會(huì)依次執(zhí)行相應(yīng)的方法，值得注意的是ApplicationContextAware接口的setApplicationContext方法，再看一下invokeInitMethods源碼

發(fā)現(xiàn)如果實(shí)現(xiàn)了InitializingBean接口，重寫(xiě)了afterPropertiesSet方法，則會(huì)調(diào)用afterPropertiesSet方法，最后還會(huì)調(diào)用是否指定了init-method，可以通過(guò)<bean init-method>標(biāo)簽，或者@Bean注解的initMethod指定，最后再看一張applyBeanPostProcessorsAfterInitialization源碼圖

發(fā)現(xiàn)跟之前的postProcessBeforeInitialization方法類(lèi)似，也是循環(huán)遍歷實(shí)現(xiàn)了BeanPostProcessor的接口實(shí)現(xiàn)類(lèi)，執(zhí)行postProcessAfterInitialization方法。整個(gè)bean的生命執(zhí)行流程就如上面截圖所示，哪個(gè)接口的方法在哪里被調(diào)用，方法的執(zhí)行流程

最后，對(duì)bean的生命流程進(jìn)行一個(gè)流程圖的總結(jié)

三級(jí)緩存解決循環(huán)依賴(lài)

上一小節(jié)對(duì)bean的生命周期做了一個(gè)整體的流程分析，對(duì)spring如何去解決循環(huán)依賴(lài)的很有幫助。前面我們分析到填充屬性時(shí)，如果發(fā)現(xiàn)屬性還未在spring中生成，則會(huì)跑去生成屬性對(duì)象實(shí)例

我們可以看到填充屬性的時(shí)候，spring會(huì)提前將已經(jīng)實(shí)例化的bean通過(guò)ObjectFactory半成品暴露出去，為什么稱(chēng)為半成品是因?yàn)檫@時(shí)候的bean對(duì)象實(shí)例化，但是未進(jìn)行屬性填充，是一個(gè)不完整的bean實(shí)例對(duì)象

spring利用singletonObjects, earlySingletonObjects, singletonFactories三級(jí)緩存去解決的，所說(shuō)的緩存其實(shí)也就是三個(gè)Map

可以看到三級(jí)緩存各自保存的對(duì)象，這里重點(diǎn)關(guān)注二級(jí)緩存earlySingletonObjects和三級(jí)緩存singletonFactory，一級(jí)緩存可以進(jìn)行忽略。前面我們講過(guò)先實(shí)例化的bean會(huì)通過(guò)ObjectFactory半成品提前暴露在三級(jí)緩存中

singletonFactory是傳入的一個(gè)匿名內(nèi)部類(lèi)，調(diào)用ObjectFactory.getObject()最終會(huì)調(diào)用getEarlyBeanReference方法。再來(lái)看看循環(huán)依賴(lài)中是怎么拿其它半成品的實(shí)例對(duì)象的。

我們假設(shè)現(xiàn)在有這樣的場(chǎng)景AService依賴(lài)BService，BService依賴(lài)AService

1. AService首先實(shí)例化，實(shí)例化通過(guò)ObjectFactory半成品暴露在三級(jí)緩存中

2. 填充屬性BService，發(fā)現(xiàn)BService還未進(jìn)行過(guò)加載，就會(huì)先去加載BService

3. 再加載BService的過(guò)程中，實(shí)例化，也通過(guò)ObjectFactory半成品暴露在三級(jí)緩存

4. 填充屬性AService的時(shí)候，這時(shí)候能夠從三級(jí)緩存中拿到半成品的ObjectFactory

拿到ObjectFactory對(duì)象后，調(diào)用ObjectFactory.getObject()方法最終會(huì)調(diào)用getEarlyBeanReference()方法，getEarlyBeanReference這個(gè)方法主要邏輯大概描述下如果bean被AOP切面代理則返回的是beanProxy對(duì)象，如果未被代理則返回的是原bean實(shí)例，這時(shí)我們會(huì)發(fā)現(xiàn)能夠拿到bean實(shí)例(屬性未填充)，然后從三級(jí)緩存移除，放到二級(jí)緩存earlySingletonObjects中，而此時(shí)B注入的是一個(gè)半成品的實(shí)例A對(duì)象，不過(guò)隨著B(niǎo)初始化完成后，A會(huì)繼續(xù)進(jìn)行后續(xù)的初始化操作，最終B會(huì)注入的是一個(gè)完整的A實(shí)例，因?yàn)樵趦?nèi)存中它們是同一個(gè)對(duì)象。下面是重點(diǎn)，我們發(fā)現(xiàn)這個(gè)二級(jí)緩存好像顯得有點(diǎn)多余，好像可以去掉，只需要一級(jí)和三級(jí)緩存也可以做到解決循環(huán)依賴(lài)的問(wèn)題？？？

只要兩個(gè)緩存確實(shí)可以做到解決循環(huán)依賴(lài)的問(wèn)題，但是有一個(gè)前提這個(gè)bean沒(méi)被AOP進(jìn)行切面代理，如果這個(gè)bean被AOP進(jìn)行了切面代理，那么只使用兩個(gè)緩存是無(wú)法解決問(wèn)題，下面來(lái)看一下bean被AOP進(jìn)行了切面代理的場(chǎng)景

我們發(fā)現(xiàn)AService的testAopProxy被AOP代理了，看看傳入的匿名內(nèi)部類(lèi)的getEarlyBeanReference返回的是什么對(duì)象

發(fā)現(xiàn)singletonFactory.getObject()返回的是一個(gè)AService的代理對(duì)象，還是被CGLIB代理的。再看一張?jiān)賵?zhí)行一遍singletonFactory.getObject()返回的是否是同一個(gè)AService的代理對(duì)象

我們會(huì)發(fā)現(xiàn)再執(zhí)行一遍singleFactory.getObject()方法又是一個(gè)新的代理對(duì)象，這就會(huì)有問(wèn)題了，因?yàn)锳Service是單例的，每次執(zhí)行singleFactory.getObject()方法又會(huì)產(chǎn)生新的代理對(duì)象，假設(shè)這里只有一級(jí)和三級(jí)緩存的話(huà)，我每次從三級(jí)緩存中拿到singleFactory對(duì)象，執(zhí)行g(shù)etObject()方法又會(huì)產(chǎn)生新的代理對(duì)象，這是不行的，因?yàn)锳Service是單例的，所有這里我們要借助二級(jí)緩存來(lái)解決這個(gè)問(wèn)題，將執(zhí)行了singleFactory.getObject()產(chǎn)生的對(duì)象放到二級(jí)緩存中去，后面去二級(jí)緩存中拿，沒(méi)必要再執(zhí)行一遍singletonFactory.getObject()方法再產(chǎn)生一個(gè)新的代理對(duì)象，保證始終只有一個(gè)代理對(duì)象。還有一個(gè)注意的點(diǎn)

既然singleFactory.getObject()返回的是代理對(duì)象，那么注入的也應(yīng)該是代理對(duì)象，我們可以看到注入的確實(shí)是經(jīng)過(guò)CGLIB代理的AService對(duì)象。所以如果沒(méi)有AOP的話(huà)確實(shí)可以?xún)杉?jí)緩存就可以解決循環(huán)依賴(lài)的問(wèn)題，如果加上AOP，兩級(jí)緩存是無(wú)法解決的，不可能每次執(zhí)行singleFactory.getObject()方法都給我產(chǎn)生一個(gè)新的代理對(duì)象，所以還要借助另外一個(gè)緩存來(lái)保存產(chǎn)生的代理對(duì)象

總結(jié)

前面先講到bean的加載流程，了解了bean加載流程對(duì)spring如何解決循環(huán)依賴(lài)的問(wèn)題很有幫助，后面再分析到spring為什么需要利用到三級(jí)緩存解決循環(huán)依賴(lài)問(wèn)題，而不是二級(jí)緩存。網(wǎng)上可以試試AOP的情形，實(shí)踐一下就能明白二級(jí)緩存為什么解決不了AOP代理的場(chǎng)景了

在工作中，一直認(rèn)為編程代碼不是最重要的，重要的是在工作中所養(yǎng)成的編程思維。

到此這篇關(guān)于Spring為何需要三級(jí)緩存解決循環(huán)依賴(lài)的文章就介紹到這了,更多相關(guān)Spring三級(jí)緩存解決循環(huán)依賴(lài)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論