前言

俗話說：金三銀四，到了這種季節(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ā)現只剩下兩個流程：對象的實例化和屬性填充

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

那么我們現在就基于這兩個核心流程出發(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表示那我也不知道用哪個呀，同樣進入兜底策略：使用無參構造器(沒有將拋出異常)

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

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

對象實例化

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

負責角色：ConstructorResolver

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

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

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

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

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

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

規(guī)則如下：

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

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

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

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

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

2. Spring是如何處理實例化異常的？

當一個beanClass中出現多個構造器，但是有部分構造器的需要的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、將根據優(yōu)先級規(guī)則排序好的構造器進行遍歷

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

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

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

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

推導過程

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

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

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

處理beanDefinition

功能描述：處理BeanDefintion的元數據信息

負責角色：

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

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

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

1、遍歷beanClass中的所有Field、Method（java中統稱為Member）

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

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

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

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

其中，AutowiredAnnotationBeanPostProcessor和InjectionMetadata的結構如下

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

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

屬性填充

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

角色：

1、AutowiredAnnotationBeanPostProcessor

2、CommonAnnotationBeanPostProcessor

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

我們同樣以AutowiredAnnotationBeanPostProcessor為例

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

2、遍歷InjectionMetadata中的checkedElements集合

3、取出Element中的Member，根據Member的類型在Spring中獲取Bean

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

推導過程

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

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

1、invokeAwareMethods：調用實現特定Aware接口的方法

2、applyBeanPostProcessorsBeforeInitialization：初始化前的處理

3、invokeInitMethods：調用初始化方法

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);
???}
??}
?}

初始化前的處理

功能：調用初始化方法前的一些操作

角色：

1、InitDestroyAnnotationBeanPostProcessor：處理@PostContrust注解

2、ApplicationContextAwareProcessor：處理一系列Aware接口的回調方法

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

1.InitDestroyAnnotationBeanPostProcessor

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

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

2、遍歷LifecycleMetadata中的checkedInitMethods集合

3、使用反射進行調用

2.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、實現InitializingBean接口的afterPropertiesSet方法

2、@Bean注解中的initMethod屬性

調用順序是先調用afterPropertiesSet再initMethod

1、判斷Bean是否實現InitializingBean接口

2、是則將Bean強轉成InitializingBean，調用afterPropertiesSet方法

3、判斷BeanDefinition中是否有initMethod

4、是則找到對應的initMethod，通過反射進行調用

初始化后的處理

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

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

ApplicationListenerDetector的流程如下

1、判斷Bean是否是個ApplicationListener

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

補充流程圖

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

同樣還有其他的一些邏輯

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

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

功能：由后置處理器返回Bean，達到中止創(chuàng)建Bean的效果

角色：無，Spring的內置后置處理器中，無實現。

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必然不能為空，因為這是必須要注入的。

現在我們自定義一個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;
?}
}

測試結果如下

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

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

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

3、中止填充屬性操作

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

實現手段為實現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;
?}
}

4、注冊Bean的銷毀方法

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

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

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

完整流程圖

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

我是敖丙，你知道的越多，你不知道的越多，感謝各位人才的：點贊、收藏和評論，我們下期見！