帶著問題去分析：Spring Bean 生命週期
1: Bean在Spring容器中是如何儲存和定義的
Bean在Spring中的定義是_org.springframework.beans.factory.config.BeanDefinition_介面，BeanDefinition裡面儲存的就是我們編寫的Java類在Spring中的後設資料，包括了以下主要的後設資料資訊：
1：Scope(Bean型別)：包括了單例Bean（Singleton）和多範例Bean（Prototype）
2：BeanClass: Bean的Class型別
3：LazyInit：Bean是否需要延遲載入
4：AutowireMode：自動注入型別
5：DependsOn：Bean所依賴的其他Bean的名稱，Spring會先初始化依賴的Bean
6：PropertyValues：Bean的成員變數屬性值
7：InitMethodName：Bean的初始化方法名稱
8：DestroyMethodName：Bean的銷燬方法名稱
同時BeanDefinition是儲存到_org.springframework.beans.factory.support.DefaultListableBeanFactory類中維護的BeanDefinitionMap_中的，原始碼如下：
Map<String, BeanDefinition> beanDefinitionMap = new ConcurrentHashMap<>(256);
瞭解了BeanDefinition的基礎資訊和儲存位置後，接下來看看建立好的Bean範例是儲存在什麼地方的，建立好的Bean是儲存在：_org.springframework.beans.factory.support.DefaultSingletonBeanRegistry_類中的
_singletonObjects_中的，Key是Bean的名稱，Value就是建立好的Bean範例：
Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
瞭解了基本資訊之後，就可以帶著下面兩個關鍵問題去分析Spring Bean的生命週期了：
1：Java類是如何被 Spring 掃描從而變成 BeanDefinition 的？
2：BeanDefinition是如何被 Spring 加工建立成我們可以直接使用的 Bean範例的?
2：Java類是如何被Spring掃描成為BeanDefinition的？
在Spring中定義Bean的方式有非常多，例如使用XML檔案、註解，包括：@Component，@Service，@Configuration等，下面就以@Component註解為例來探究Spring是如何掃描我們的Bean的。我們知道使用@Component註解來標記Bean是需要配合@ComponentScan註解來使用的，而我們的主啟動類上標註的@SpringBootApplication註解中就預設繼承了@ComponentScan註解
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication
所以最初的問題就轉化成了@ComponentScan註解是如何在Spring中運作的
2.1 @ComponentScan註解是如何運作的
在Spring框架中，這個註解對應的處理類是_ComponentScanAnnotationParser，這個類的parse_方法是主要的處理邏輯，這個方法簡要處理邏輯如下：
1：獲取@ComponentScan註解中的basePackage屬性，若沒有則預設為該註解所標註類所在的包路徑
2：使用ClassPathBeanDefinitionScanner的scanCandidateComponents方法掃描classpath:+basePackage+/*.class**下的所有類資原始檔
3：最後迴圈判斷掃描的所有類資原始檔，判斷是否包含@Component註解，若有則將這些類註冊到beandefinitionMap中
自此，我們程式碼裡寫的Java類，就被Spring掃描成BeanDefinition儲存到了BeanDefinitionMap中了，掃描的細節大家可以去看看這個類的原始碼
3：Spring如何建立我們的Bean範例的
Spring把我們編寫的Java類掃描成BeanDefinition之後，就會開始建立我們的Bean範例了，Spring將建立Bean的方法交給了_org.springframework.beans.factory.support.AbstractBeanFactory#getBean_方法，接下來就來看看getBean方法是如何建立Bean的
getBean方法的呼叫邏輯如下：getBean--> doGetBean --> createBean --> doCreateBean，最終Spring會使用org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#doCreateBean方法來建立Bean，建立Bean範例的主要邏輯分為了四個部分：建立Bean範例，填充Bean屬性，初始化Bean，銷燬Bean，接下來我們分別對這個四個部分進行探究
3.1 建立Bean範例
建立Bean範例的方法入口如下：
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#__createBeanInstance
if (instanceWrapper == null) {
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
這個方法的主要邏輯是：推斷出建立該Bean的構造器方法和引數，然後使用Java反射去建立Bean範例
3.2 填充Bean屬性值populateBean方法
在這個方法中，主要是解析Bean需要注入的成員屬性，然後將這些屬性注入到該Bean中，如果該Bean有依賴的其他Bean則會優先去建立依賴的Bean，然後返回來繼續建立該Bean，注意這裡就會產生Bean建立的迴圈依賴問題，在本文的第6節中會詳細說明
3.4：初始化Bean（initializeBean方法)
初始化Bean主要包括了四個部分：
3.4.1：invokeAwareMethods
在這個方法中主要呼叫實現的Aware介面中的方法，包括了BeanNameAware.setBeanName，BeanClassLoaderAware.setBeanClassLoader，BeanFactoryAware.setBeanFactory，這三個方法
Aware介面的功能：通過呼叫Aware介面中的set方法，將Spring容器中對應的Bean注入到正在建立的Bean中
3.4.2：呼叫前置處理方法：applyBeanPostProcessorsBeforeInitialization
在這個方法中主要是獲取Spring容器中所有實現了_org.springframework.beans.factory.config.BeanPostProcessor介面的的實現類，然後迴圈呼叫postProcessBeforeInitialization_方法來加工正在建立的Bean
所以在這個方法中我們可以自定義_BeanPostProcessor_來擴充套件Bean的功能，實現自己的加工邏輯
3.4.3：呼叫Bean相關的初始化方法：
3.4.3.1 如果是InitializingBean則呼叫afterPropertiesSet方法
在這個流程中，Spring框架會判斷正在建立的Bean是否實現了InitializingBean介面，如果實現了就會呼叫_afterPropertiesSet_方法來執行程式碼邏輯。
3.4.3.2 呼叫自定義初始化方法：initMethod
在這個流程中主要呼叫我們自定義的初始化方法，例如在xml檔案中設定的_init-method和destory-method或者使用註解設定的@Bean(initMethod = "initMethod", destroyMethod = "destroyMethod")_ 方法
3.4.3.3：呼叫後置處理方法：applyBeanPostProcessorsAfterInitialization
在這個方法中主要是獲取Spring容器中所有實現了_org.springframework.beans.factory.config.BeanPostProcessor介面的的實現類，然後迴圈呼叫postProcessAfterInitialization_來加工正在建立的Bean
在這個方法中我們可以自定義_BeanPostProcessor_來擴充套件Bean的功能，實現自己的加工邏輯
4：註冊Bean銷燬方法
在這裡主要是註冊Bean銷燬時Spring回掉的方法例如：
1：xml檔案中設定的destroy-method方法或者_@Bean註解中設定的destroyMethod_方法
2：_org.springframework.beans.factory.DisposableBean介面中的destory_方法
5：總結
到這裡，從我們編寫的Java類到Spring容器中可使用的Bean範例的建立過程就完整的梳理完成了，瞭解Bean的建立過程能夠使我們更加熟悉Bean的使用方法，同時我們也可以在建立Bean的過程中新增自己的處理邏輯，從而實現將自己的元件接入Spring框架
6：Spring迴圈依賴的解決方法
Spring在建立Bean範例的時候，有時避免不了我們編寫的Java類存在互相依賴的情況，如果Spring對這種互相依賴的情況不做處理，那麼就會產生建立Bean範例的死迴圈問題，所以Spring對於這種情況必須特殊處理，下面就來探究Spring是如何巧妙處理Bean之間的迴圈依賴問題
6.1 暴露勾點方法getEarlyBeanReference
首先對於單範例型別的Bean來說，Spring在建立Bean的時候，會提前暴露一個勾點方法來獲取這個正在建立中的Bean的地址參照，其程式碼如下：
如上面的程式碼所示，此時會在_singletonFactories這個Map中提前儲存這個勾點方法singletonFactory_，從而能夠提前對外暴露這個Bean的地址參照，那麼為什麼獲取地址參照需要包裝成複雜的方法呢？下面會解釋
6.2 其他Bean獲取提前暴露的Bean的地址參照
當其他Bean需要依賴正在建立中的Bean的時候，就會呼叫getSingleton方法來獲取需要的Bean的地址參照
如上訴程式碼所示，在獲取Bean的時候會從三個地方來獲取
1：singletonObjects :這個是存放已經完全建立完成的Bean範例的Map
2：earlySingletonObjects :這個是存放用提前暴露的勾點方法建立好的Bean範例的Map
3：singletonFactories :這個是用來存放勾點方法的Map
當獲取依賴的Bean的時候，就會呼叫勾點方法getEarlyBeanReference來獲取提前暴露的Bean的參照，這個方法的原始碼如下：
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
Object exposedObject = bean;
if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
}
}
}
return exposedObject;
}
如上面的原始碼所示，這個方法主要是需要呼叫SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference方法來提前處理一下尚未建立完成的Bean，而getEarlyBeanReference方法有邏輯的實現類只有一個**org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator，**這個類就是建立Aop代理的類，其程式碼如下：
public Object getEarlyBeanReference(Object bean, String beanName) {
Object cacheKey = this.getCacheKey(bean.getClass(), beanName);
//提前標記這個bean已經建立過代理物件了
this.earlyProxyReferences.put(cacheKey, bean);
//按條件建立代理物件
return this.wrapIfNecessary(bean, beanName, cacheKey);
}
如上面的程式碼所示，這段程式碼的主要目標就是判斷提前暴露的Bean是否需要做動態代理，需要的話就會返回提前暴露的Bean的動態代理物件
那麼這裡為什麼要去判斷是否需要動態代理呢？考慮下面這種情況
1：如果這裡不返回這個Bean的動態代理物件，但是這個Bean在後續的初始化流程中會存在動態代理：
舉例：這裡假設A依賴B，B又依賴A，此時B正在獲取A提前暴露的參照，如果這時將A本身的地址參照返回給B，那麼B裡面就會儲存A原始的地址參照，當B建立完成後，程式返回去建立A時，結果A在初始化的流程（initializingBean）中發生了動態代理，那麼這時Spring容器中實際使用的是A的動態代理物件，而B卻持有了原始A的參照，那麼這時容器中就會存在A原始的參照以及A的動態代理的參照，從而產生歧義，這就是為什麼需要提前去判斷是否需要建立動態代理的原因，__這個原因的問題在於填充屬性populateBean流程在初始化流程（initializingBean）之前，而建立動態代理的過程在初始化流程中
6.3 判斷Bean的地址是否發生變化
Spring在Bean初始化之後，又判斷了一下Bean初始化之後的地址是否發生了變化，其程式碼邏輯如下所示：
if (earlySingletonExposure) {
Object earlySingletonReference = getSingleton(beanName, false);
//判斷是否觸發了提前建立bean的邏輯(getEarlyBeanReference)
//如果有其他bean觸發了提前建立bean的邏輯，那麼這裡就不為null
if (earlySingletonReference != null) {
//判斷參照地址是否發生了變化
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
}
}
那麼這裡為什麼需要在初始化之後繼續判斷Bean的地址是否發生了變化呢？
這是因為，如果存在迴圈依賴，同時Bean在初始化的流程(initializingBean)中又發生了額外的動態代理，例如，除了在**getEarlyBeanReference中發生的動態代理之外，還有額外的動態代理髮生了，也就是發生了兩次動態代理，那麼這時Bean的地址與getEarlyBeanReference流程中產生的Bean的地址就不一樣了，**這時如果不處理這種情況，又會出現Spring容器中同時存在兩種不同的參照物件，又會造成歧義，所以Spring需要避免這種情況的存在
6.4 如果Bean地址發生變化則判斷是否存在強依賴的Bean
Spring在Bean的建立過程中如果出現了上訴6.3節的情況時，Spring採取了下面的方法進行處理：
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
//獲取該Bean依賴的Bean
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
//去除因為型別檢查而建立的Bean(doGetBean方法typeCheckOnly引數來控制)
for (String dependentBean : dependentBeans) {
if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
actualDependentBeans.add(dependentBean);
}
}
//如果去除因為型別檢查而建立的bean之外還存在依賴的bean
//(這些剩下的bean就是spring實際需要使用的)那麼就會丟擲異常，阻止問題出現
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 " +
"'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.");
}
}
上面這段程式碼就是Spring處理上訴情況的邏輯，首先明確的是Spring不允許上訴情況發生，Spring對於Bean的參照地址發生變化的情況，Spring首先會判斷依賴的Bean是否已經完全建立完畢，如果存在完全建立完成的Bean就會直接丟擲異常，因為這些完全建立完成的依賴Bean中持有的參照已經是舊地址參照了
具體的處理邏輯是：先拿到該Bean所有依賴的Bean，然後從這些Bean中排除僅僅是因為型別檢查而建立的Bean，如果排除這些Bean之後，還有依賴的Bean，那麼這些Bean就是可能存在迴圈依賴並且是強依賴的Bean（這些Bean中持有的參照地址是老地址，所以會存在問題），Spring就會及時丟擲異常，避免發生問題
作者：京東零售 鍾磊
來源：京東雲開發者社群 自猿其說Tech 轉載請註明來源