Bean在Spring中的定義是_org.springframework.beans.factory.config.BeanDefinition_介面，BeanDefinition裡面存儲的就是我們編寫的Java類在Spring中的元數據 ...

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

帶著問題去分析：Spring Bean 生命周期