聊一聊Spring Bean 的生命周期
講一講 Spring Bean 的生命周期算是面試時候一道非常經典的問題了！
如果沒有研究過 Spring 源碼，單純去背面試題，這個問題也是可以回答出來的，但是單純的背缺乏理解，而且面試一緊張，就容易背岔了。但是如果你從頭到尾看了松哥的 Spring 源碼分析，那么這個問題就不需要背了，就根據自己對 Spring 源碼的理解講出來就行了。
在前面的文章中，松哥和大家分析了 Spring 中 Bean 的創建是在 createBean 方法中完成的，在該方法中，真正干活的實際上是 doCreateBean 方法，具體位置在 AbstractAutowireCapableBeanFactory#doCreateBean，小伙伴們在面試時候常被問到的 Spring Bean 的生命周期，實際上就是問 doCreateBean 方法的執行邏輯。
doCreateBean 方法整體上來說，干了四件事：
- Bean 的實例化。
- Bean 屬性填充。
- Bean 初始化。
- Bean 銷毀方法注冊。
這里大家注意區分實例化和初始化兩個方法，實例化是指通過反射創建出來 Bean 實例的過程，而初始化則是調用一些回調函數進行 bean 的一些預處理。
1. 實例化
// Instantiate the bean.
BeanWrapper instanceWrapper = null;
if (mbd.isSingleton()) {
instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
}
if (instanceWrapper == null) {
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
Object bean = instanceWrapper.getWrappedInstance();
Class<?> beanType = instanceWrapper.getWrappedClass();
if (beanType != NullBean.class) {
mbd.resolvedTargetType = beanType;
}這段代碼的最終目的是為了獲取到一個 bean 實例。獲取之前先去檢查如果有該 bean 尚未完成的 factoryBean 實例就先移除掉。
createBeanInstance 方法就是大家閉著眼睛也能猜出來的通過反射創建 bean 實例過程，最后我們拿到的 bean 實例就是這個 bean。
實例化完成之后，還有兩個小細節。
一個是預留了后置處理器修改 BeanDefinition 的接口，在這里可以對 BeanDefinition 進行修改，這塊通常用來處理通過注解注入值的情況，這個松哥在之前的文章中也有詳細介紹過，小伙伴們參見：一個特殊的 BeanPostProcessor。
另外一個則是對于循環依賴的處理。
松哥之前的文章中已經和小伙伴們詳細分析了循環依賴的解決思路，參見：如何通過三級緩存解決 Spring 循環依賴。
這里要做的工作就是根據當前 Bean 的情況，將 Bean 存入到三級緩存中（二級緩存中不存）：
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
isSingletonCurrentlyInCreation(beanName));
if (earlySingletonExposure) {
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}這塊代碼的具體含義在之前的文章中松哥都和大家分析過了，這里就不再啰嗦了，感興趣的小伙伴戳這里：透過源碼，捋清楚循環依賴到底是如何解決的！。
2. 屬性填充
populateBean(beanName, mbd, instanceWrapper);這一句就是屬性填充的環節了。屬性填充就是一個 Bean 中我們通過各種注解如 @Autowired 等注入的對象，@Value 注入的字符串，這些統一都在 populateBean 中進行處理。具體的代碼細節松哥在之前的文章中也和大家講過了：@Autowired 到底是怎么把變量注入進來的？。
3. 初始化
exposedObject = initializeBean(beanName, exposedObject, mbd);初始化主要是干這樣四件事：
protected Object initializeBean(String beanName, Object bean, @Nullable RootBeanDefinition mbd) {
invokeAwareMethods(beanName, bean);
Object wrappedBean = bean;
if (mbd == null || !mbd.isSynthetic()) {
wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
}
try {
invokeInitMethods(beanName, wrappedBean, mbd);
}
catch (Throwable ex) {
throw new BeanCreationException(
(mbd != null ? mbd.getResourceDescription() : null), beanName, ex.getMessage(), ex);
}
if (mbd == null || !mbd.isSynthetic()) {
wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
}
return wrappedBean;
}- invokeAwareMethods：如果當前 bean 實現了 Aware 接口，那么 Aware 接口相關的方法就在 invokeAwareMethods 方法中被觸發。
- applyBeanPostProcessorsBeforeInitialization：這個是執行 BeanPostProcessor#postProcessBeforeInitialization 方法。
- invokeInitMethods：這個里邊是干兩件事，如果我們的 Bean 實現了 InitializingBean 接口，那么該接口中的 afterPropertiesSet 方法就在這里被觸發；另一方面就是如果我們通過配置文件 Bean 的初始化方法（XML 文件中的 init-method 屬性），那么也會在這里被觸發。
- applyBeanPostProcessorsAfterInitialization：這個是執行 BeanPostProcessor#postProcessAfterInitialization 方法。
這里需要注意的一點是，通過在 XML 文件中配置的 init-method 屬性，這個是在第 3 步被觸發執行的；但是如果是通過 @PostConstruct 注解標記的 Bean 的初始化方法，則是通過 BeanPostProcessor 來處理的，具體是在 InitDestroyAnnotationBeanPostProcessor#postProcessBeforeInitialization 方法中處理的。這兩種看起來作用類似的 Bean 初始化方法，底層處理邏輯并不相同。
初始化完成之后，還有一個關于循環依賴的處理和判斷。
if (earlySingletonExposure) {
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
}
else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
String[] dependentBeans = getDependentBeans(beanName);
Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
for (String dependentBean : dependentBeans) {
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 " +
"'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.");
}
}
}
}這段代碼主要是防止 Spring 容器中創建出來的當前 Bean 和被其他 Bean 所依賴的 Bean 不是同一個。例如有 A 和 B 兩個類，Spring 根據既有配置，給 A 生成了代理類，但是 B 引用的并不是 A 的代理對象，而是 A 的原始對象，此時就會有問題。所以這里主要是去判斷，確保容器中和被使用的 A 是同一個。
檢查的思路就是先去二級緩存中查找，二級緩存中如果存在，說明這個 Bean 因為循環依賴的原因已經被引用過了（被引用過的 Bean 會存入到二級緩存中），此時去判斷 exposedObject 和 bean 是否為同一個 Bean，正常情況下，這兩個當然是同一個 Bean，因為 exposedObject 和 bean 指向同一個內存地址。什么情況下，這兩個 Bean 會不同呢？如果在 Bean 的后置處理器中，我們使用新的 Bean 替換了舊的 Bean，就會導致最終拿到的 exposedObject 和 bean 兩個變量指向的地址不再相同。如果不相同，就要檢查當前 Bean 是否有被容器中的其他 Bean 所依賴了，如果有，并且使用了當前 Bean 的 Bean 還正在創建中，那么就趕緊刪除掉重新創建，如果使用了當前 Bean 的 Bean 已經創建完成了，那就沒辦法了，只能拋出異常了。
4. 銷毀
銷毀并不是說要立馬把 Bean 給銷毀掉，這 Bean 剛創建出來還沒使用呢，怎么就給銷毀了呢？
這里的銷毀是說把 Bean 的銷毀方法先記錄下來，將來需要銷毀 Bean 或者銷毀容器的時候，就調用這些方法去釋放 Bean 所持有的資源。
// Register bean as disposable.
try {
registerDisposableBeanIfNecessary(beanName, bean, mbd);Bean 的銷毀方法我們可以通過注解或者是 XML 文件進行配置。使用注解的話就是 @PreDestroy 注解，被該注解標記的方法可以在 Bean 銷毀之前執行，我們可以在該方法中釋放資源；也可以使用 XML 文件進行配置 destroy-method=""，通過該屬性指定 Bean 銷毀時候需要執行的方法。另外，當前 Bean 也可以通過實現 DisposableBean 接口，并重寫該接口中的 destroy 方法，那么容器銷毀的時候，這個方法會被自動調用以釋放資源。
除了這三種常見的方法之外，還有一個辦法就是如果當前 Bean 實現了 AutoCloseable 接口，那么當前類中如果存在名為 close 的方法或者名為 shutdown 的方法，那么對應的方法就會被自動調用。
好啦，大致的流程就是這樣了，小伙伴們不妨據此畫一個流程圖看看。
