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 轉載請註明來源