前言

俗話說：金三銀四，到了這種季節(jié)，有一種叫做程序員的生物就開始活躍了起來。

這倆天，同事出去面試，她回來就問我：為啥這些面試官老愛問Spring，特別是Bean的生命周期，到底啥是Bean的生命周期呀，跟我說說唄。

那咱就來聊聊這個話題，本文主要分為兩點進行闡述：

1、什么是Bean的生命周期?

2、Bean的生命周期是怎樣的?

先給大家看一下完整的bean生命周期，不懂沒關系后面會講。

什么是Bean的生命周期

我們知道，在Java中，萬物皆對象，這些對象有生命周期：實例化 -> gc回收 ，而Bean同樣也是Java中的對象，只是在這同時，Spring又賦予了它更多的意義。

于是乎，我們將Bean從在Spring中創(chuàng)建開始，到Bean被銷毀結束，這一過程稱之為Bean的生命周期。

那到底Bean在Spring中的創(chuàng)建過程是怎樣的呢?

Bean的生命周期是怎樣的在Spring中，Bean的創(chuàng)建過程看起來復雜，但實際上邏輯分明。

如果我們將所有擴展性流程拋開，你會發(fā)現(xiàn)只剩下兩個流程：對象的實例化和屬性填充。

我們在《深入淺出Spring架構設計》文中手寫的Spring，也只是完成了這兩個流程，這足以說明只需要這兩個流程就能完成一個簡單的Spring框架，那其他的流程又是什么呢?他們又有什么作用?

那么我們現(xiàn)在就基于這兩個核心流程出發(fā)，嘗試完善整個Spring的Bean生命周期。

推導過程

開始時，我們只有兩個流程：對象的實例化和屬性填充。

我們知道，對象的實例化就是在Java里使用類構造器進行創(chuàng)建對象。而一個類中可能有很多的構造器，那么我們怎么才能知道使用哪個構造器進行實例化對象呢?

所以說，在實例化之前，還得先做一件事情：確定候選的構造器，也稱之為構造器推斷。

構造器推斷

• 功能描述：找尋beanClass中所有符合候選條件的構造器。
• 負責角色：AutowiredAnnotationBeanPostProcessor。
• 候選條件：構造器上添加了@Autowired注解。

推斷流程：

1、獲取beanClass中的所有構造器進行遍歷，判斷構造器上是否標識@Autowired注解，是則將構造器添加到候選構造器集合中。

2、并進一步判斷Autowired注解中required屬性是否為true(默認為true)，是則表示該beanClass已存在指定實例化的構造器，不可再有其他加了@Autowired注解的構造器，如果有則拋出異常。

3、如果Autowired注解中required屬性為false，則可繼續(xù)添加其他@Autowired(required=false)標識的構造器。

4、如果候選構造器集合不為空(有Autowired標識的構造器)，并且beanClass中還有個空構造器，那么同樣將空構造器也加入候選構造器集合中。

5、如果候選構造器集合為空，但是beanClass中只有一個構造器且該構造器有參，那么將該構造器加入候選構造器集合中。

流程圖：

當構造器遍歷完畢之后，還有些許邏輯。

以上判斷條件很多，但始終是圍繞這一個邏輯：這個beanClass中有沒有被Autowired標識的構造器，有的話required是true還是false，如果是true, 那其他的構造器都不要了。如果是false，那想加多少個構造器就加多少個。

咦，那要是沒有Autowired標識的構造器呢?

框架嘛，都是要兜底的，這里就是看beanClass中是不是只有一個構造器且是有參的。

那我要是只有個無參的構造器呢?

那確實就是沒有候選的構造器了，但是Spring最后又兜底了一次，在沒有候選構造器時默認使用無參構造器。

那我要是有很多個構造器呢?

Spring表示那我也不知道用哪個呀，同樣進入兜底策略：使用無參構造器(沒有將拋出異常)。

那么這就是構造器推斷流程了，我們將它加入到流程圖中。

在得到候選的構造器之后，就可以對對象進行實例化了，那么實例化的過程是怎樣的呢?

對象實例化

• 功能描述：根據(jù)候選構造器集合中的構造器優(yōu)先級對beanClass進行實例化。
• 負責角色：ConstructorResolver。

對象實例化的過程主要有兩個方面需要關注：

1、構造器的優(yōu)先級是怎樣的?

2、如果有多個構造器，但是有部分構造器的需要的bean并不存在于Spring容器中會發(fā)生什么?也就是出現(xiàn)了異常怎么處理?

一、 構造器的優(yōu)先級是怎樣的?

在Java中，多個構造器稱之為構造器重載，重載的方式有兩種：參數(shù)的數(shù)量不同，參數(shù)的類型不同。

在Spring中，優(yōu)先級則是由構造器的修飾符(public or private)和參數(shù)的數(shù)量決定。

規(guī)則如下：

1、public修飾的構造器 > private修飾的構造器。

2、修飾符相同的情況下參數(shù)數(shù)量更多的優(yōu)先。

這段流程很簡單，代碼只有兩行：

// 如果一個是public,一個不是,那么public優(yōu)先
int result = Boolean.compare(Modifier.isPublic(e2.getModifiers()), Modifier.isPublic(e1.getModifiers()));
// 都是public，參數(shù)多的優(yōu)先
return result != 0 ? result : Integer.compare(e2.getParameterCount(), e1.getParameterCount());

文中描述的規(guī)則是public > private, 只是為了更好的理解，實際上比較的是public和非public。

二、Spring是如何處理實例化異常的?

當一個beanClass中出現(xiàn)多個構造器，但是有部分構造器的需要的bean并不存在于Spring容器中，此時會發(fā)生什么呢?

比如以下案例中，InstanceA具有三個構造方法，其中InstanceB并未注入到Spring中。

@Component
public class InstanceA {
 @Autowired(required = false)
 public InstanceA(InstanceB instanceB){
  System.out.println("instance B ...");
 }
 @Autowired(required = false)
 public InstanceA(InstanceC instanceC){
  System.out.println("instance C ...");
 }
 @Autowired(required = false)
 public InstanceA(InstanceB instanceB, InstanceC instanceC, InstanceD InstanceD){
  System.out.println("instance B C D...");
 }
}

那么啟動時是報錯呢?還是選擇只有InstanceC的構造器進行實例化?

運行結果會告訴你：Spring最終使用了只有InstanceC的構造器。

這一部分的具體過程如下：

1、將根據(jù)優(yōu)先級規(guī)則排序好的構造器進行遍歷。

2、逐個進行嘗試查找構造器中的需要的bean是否都在Spring容器中，如果成功找到將該構造器標記為有效構造器，并立即退出遍歷。

3、否則記錄異常繼續(xù)嘗試使用下一個構造器。

4、當所有構造器都遍歷完畢仍未找到有效的構造器，拋出記錄的異常。

5、使用有效構造器進行實例化。

推導過程

到這里，beanClass實例化了一個bean，接下來需要做的便是對bean進行賦值，但我們知道，Spring中可以進行賦值的對象不僅有通過@Autowired標識的屬性，還可以是@Value,@Resource,@Inject等等。

為此，Spring為了達到可擴展性，將獲取被注解標識的屬性的過程與實際賦值的過程進行了分離。

該過程在Spring中被稱為處理beanDefinition。

處理beanDefinition

功能描述：處理BeanDefintion的元數(shù)據(jù)信息。

負責角色：

1、AutowiredAnnotationBeanPostProcessor：處理@Autowird,@Value,@Inject注解。

2、CommonAnnotationBeanPostProcessor：處理@PostConstruct,@PreDestroy,@Resource注解。

這兩個后置處理器的處理過程十分類似, 我們以AutowiredAnnotationBeanPostProcessor為例：

1、遍歷beanClass中的所有Field、Method(java中統(tǒng)稱為Member)。

2、判斷Member是否標識@Autowird,@Value,@Inject注解。

3、是則將該Member保存，封裝到一個叫做InjectionMetadata的類中。

4、判斷Member是否已經(jīng)被解析過，比如一個Member同時標識了@Autowired和@Resource注解，那么這個Member就會被這兩個后置處理器都處理一遍，就會造成重復保存。

5、如果沒被解析過就將該Member放置到已檢查的元素集合中，用于后續(xù)填充屬性時從這里直接拿到所有要注入的Member。

其中，AutowiredAnnotationBeanPostProcessor和InjectionMetadata的結構如下：

同樣，我們將這一部分流程也加入到流程圖中。

現(xiàn)在，beanClass中的可注入屬性都找出來了，接下來就真的要進行屬性填充了。

屬性填充

功能：對bean中需要自動裝配的屬性進行填充。

角色：

1、AutowiredAnnotationBeanPostProcessor。

2、CommonAnnotationBeanPostProcessor。

在上一個流程中，我們已經(jīng)找到了所有需要自動裝配的Member，所以這一部流程就顯得非常簡單了。

我們同樣以AutowiredAnnotationBeanPostProcessor為例。

1、使用beanName為key，從緩存中取出InjectionMetadata。

2、遍歷InjectionMetadata中的checkedElements集合。

3、取出Element中的Member，根據(jù)Member的類型在Spring中獲取Bean。

4、使用反射將獲取到的Bean設值到屬性中。

推導過程

在Spring中，Bean填充屬性之后還可以做一些初始化的邏輯，比如Spring的線程池ThreadPoolTaskExecutor在填充屬性之后的創(chuàng)建線程池邏輯，RedisTemplate的設置默認值。

Spring的初始化邏輯共分為4個部分：

1、invokeAwareMethods：調(diào)用實現(xiàn)特定Aware接口的方法。

2、applyBeanPostProcessorsBeforeInitialization：初始化前的處理。

3、invokeInitMethods：調(diào)用初始化方法。

4、applyBeanPostProcessorsAfterInitialization：初始化后的處理。

invokeAwareMethods

這塊邏輯非常簡單，我直接把源碼粘出來給大家看看就明白了。

private void invokeAwareMethods(String beanName, Object bean) {
  if (bean instanceof Aware) {
   if (bean instanceof BeanNameAware) {
    ((BeanNameAware) bean).setBeanName(beanName);
   }
   if (bean instanceof BeanClassLoaderAware) {
    ClassLoader bcl = getBeanClassLoader();
    if (bcl != null) {
     ((BeanClassLoaderAware) bean).setBeanClassLoader(bcl);
    }
   }
   if (bean instanceof BeanFactoryAware) {
    ((BeanFactoryAware) bean).setBeanFactory(AbstractAutowireCapableBeanFactory.this);
   }
  }
 }

初始化前的處理

功能：調(diào)用初始化方法前的一些操作。

角色：

1、InitDestroyAnnotationBeanPostProcessor：處理@PostContrust注解。

2、ApplicationContextAwareProcessor：處理一系列Aware接口的回調(diào)方法。

這一步驟的功能沒有太大的關聯(lián)性，完全按照使用者自己的意愿決定想在初始化方法前做些什么，我們一個一個來過。

一、InitDestroyAnnotationBeanPostProcessor

這里的邏輯與屬性填充過程非常相似，屬性填充過程是取出自動裝配相關的InjectionMetadata進行處理，而這一步則是取@PostContrust相關的Metadata進行處理，這個Metadata同樣也是在處理BeanDefinition過程解析緩存的。

1、取出處理BeanDefinition過程解析的LifecycleMetadata。

2、遍歷LifecycleMetadata中的checkedInitMethods集合。

3、使用反射進行調(diào)用。

二、ApplicationContextAwareProcessor

這一步與invokeAwareMethods大同小異，只不過是其他的一些Aware接口，同樣直接粘上代碼：

 private void invokeAwareInterfaces(Object bean) {
  if (bean instanceof EnvironmentAware) {
   ((EnvironmentAware) bean).setEnvironment(this.applicationContext.getEnvironment());
  }
  if (bean instanceof EmbeddedValueResolverAware) {
   ((EmbeddedValueResolverAware) bean).setEmbeddedValueResolver(this.embeddedValueResolver);
  }
  if (bean instanceof ResourceLoaderAware) {
   ((ResourceLoaderAware) bean).setResourceLoader(this.applicationContext);
  }
  if (bean instanceof ApplicationEventPublisherAware) {
   ((ApplicationEventPublisherAware) bean).setApplicationEventPublisher(this.applicationContext);
  }
  if (bean instanceof MessageSourceAware) {
   ((MessageSourceAware) bean).setMessageSource(this.applicationContext);
  }
  if (bean instanceof ApplicationContextAware) {
   ((ApplicationContextAware) bean).setApplicationContext(this.applicationContext);
  }
 }

初始化方法

在Spring中的初始化方法有兩種：

1、實現(xiàn)InitializingBean接口的afterPropertiesSet方法。

2、@Bean注解中的initMethod屬性。

調(diào)用順序是先調(diào)用afterPropertiesSet再initMethod。

1、判斷Bean是否實現(xiàn)InitializingBean接口。

2、是則將Bean強轉成InitializingBean，調(diào)用afterPropertiesSet方法。

3、判斷BeanDefinition中是否有initMethod。

4、是則找到對應的initMethod，通過反射進行調(diào)用。

初始化后的處理

在Spring的內(nèi)置的后置處理器中，該步驟只有ApplicationListenerDetector有相應處理邏輯：將實現(xiàn)了ApplicationListener接口的bean添加到事件監(jiān)聽器列表中.

如果使用了Aop相關功能，則會使用到AbstractAutoProxyCreator，進行創(chuàng)建代理對象。

ApplicationListenerDetector的流程如下：

1、判斷Bean是否是個ApplicationListener。

2、是則將bean存放到applicationContext的監(jiān)聽器列表中。

補充流程圖

到這里，Bean的生命周期主要部分已經(jīng)介紹完了，我們將流程圖補充一下。

同樣還有其他的一些邏輯。

一、中止創(chuàng)建Bean的過程

該過程處于Bean生命周期的最開始部分。

• 功能：由后置處理器返回Bean，達到中止創(chuàng)建Bean的效果。
• 角色：無，Spring的內(nèi)置后置處理器中，無實現(xiàn)。

Bean的生命周期十分復雜，Spring允許你直接攔截，即在創(chuàng)建Bean之前由自定義的后置處理器直接返回一個Bean給Spring，那么Spring就會使用你給的Bean，不會再走Bean生命周期流程。

案例演示：

@Component
public class Car {
 @Autowired
 private Person person;
 public void checkPerson(){
  if(person == null){
   System.out.println("person is null");
  }
 }
}

由于在Person屬性上加了@Autowired,所以正常來說person必然不能為空，因為這是必須要注入的。

現(xiàn)在我們自定義一個BeanPostProcessor進行攔截。

@Component
public class InterruptBeanPostProcessor implements InstantiationAwareBeanPostProcessor {
 @Override
 public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
  if("car".equals(beanName)){
   try {
    return beanClass.newInstance();
   } catch (InstantiationException | IllegalAccessException e) {
    e.printStackTrace();
   }
  }
  return null;
 }
}

測試結果如下:

二、提前緩存剛實例化的對象

該步驟跟隨在Spring實例化bean之后，將bean進行緩存，其目的是為了解決循環(huán)依賴問題。

該過程暫時按下不表，單獨提出放于循環(huán)依賴章節(jié)。

三、中止填充屬性操作

與中止創(chuàng)建Bean邏輯相同，Spring同樣也允許你在屬性填充前進行攔截。在Spring的內(nèi)置處理器中同樣無該實現(xiàn)。

實現(xiàn)手段為實現(xiàn)InstantiationAwareBeanPostProcessor接口，在postProcessAfterInstantiation方法中返回false。

@Component
public class InterruptBeanPostProcessor implements InstantiationAwareBeanPostProcessor {
 @Override
 public boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException {
  if(beanName.equals("car")){
   return false;
  }
  return true;
 }
}

四、注冊Bean的銷毀方法

Spring中不僅有@PostContrust、afterProperties、initMethod這些bean創(chuàng)建時的初始化方法，同樣也有bean銷毀時的@PreDestory、destroy,destroyMethod。

所以在Bean的生命周期最后一步，Spring會將具備這些銷毀方法的Bean注冊到銷毀集合中，用于系統(tǒng)關閉時進行回調(diào)。

比如線程池的關閉，連接池的關閉，注冊中心的取消注冊，都是通過它來實現(xiàn)的。

完整流程圖最后，附上開頭的Bean生命周期的完整流程圖，是不是就清晰了很多?