講一講 Spring Bean 的生命周期算是面試時候一道非常經典的問題了！

如果沒有研究過 Spring 源碼，單純去背面試題，這個問題也是可以回答出來的，但是單純的背缺乏理解，而且面試一緊張，就容易背岔了。但是如果你從頭到尾看了松哥的 Spring 源碼分析，那么這個問題就不需要背了，就根據自己對 Spring 源碼的理解講出來就行了。

在前面的文章中，松哥和大家分析了 Spring 中 Bean 的創建是在 createBean 方法中完成的，在該方法中，真正干活的實際上是 doCreateBean 方法，具體位置在 AbstractAutowireCapableBeanFactory#doCreateBean，小伙伴們在面試時候常被問到的 Spring Bean 的生命周期，實際上就是問 doCreateBean 方法的執行邏輯。

doCreateBean 方法整體上來說，干了四件事：

1. Bean 的實例化。
2. Bean 屬性填充。
3. Bean 初始化。
4. 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;
}

1. invokeAwareMethods：如果當前 bean 實現了 Aware 接口，那么 Aware 接口相關的方法就在 invokeAwareMethods 方法中被觸發。
2. applyBeanPostProcessorsBeforeInitialization：這個是執行 BeanPostProcessor#postProcessBeforeInitialization 方法。
3. invokeInitMethods：這個里邊是干兩件事，如果我們的 Bean 實現了 InitializingBean 接口，那么該接口中的 afterPropertiesSet 方法就在這里被觸發；另一方面就是如果我們通過配置文件 Bean 的初始化方法（XML 文件中的 init-method 屬性），那么也會在這里被觸發。
4. 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 的方法，那么對應的方法就會被自動調用。

好啦，大致的流程就是這樣了，小伙伴們不妨據此畫一個流程圖看看。