歡迎光臨
每天分享高質量文章
當前位置：知識星球 > 後端 > 正文

【死磕 Spring】—– IOC 之開啟 bean 的實體化行程

2018-10-31 分類：後端 閱讀(352) 評論(0)

精品專欄

 

原文出自：http://cmsblogs.com

在上篇部落格【死磕 Spring】—– 載入 bean 之 分析各 scope 的 bean 建立中有一個核心方法沒有講到 createBean() ，該方法的如下：

  1. protected abstract Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
  2.             throws BeanCreationException;

該方法定義在 AbstractBeanFactory 中。其含義是根據給定的 BeanDefinition 和 args實體化一個 bean 物件，如果該 BeanDefinition 存在父類，則該 BeanDefinition 已經合併了父類的屬性。所有 Bean 實體的建立都會委託給該方法實現。

方法接受三個引數：

  • beanName：bean 的名字

  • mbd：已經合併了父類屬性的（如果有的話）BeanDefinition

  • args：用於建構式或者工廠方法建立 bean 實體物件的引數

該抽象方法的預設實現是在類 AbstractAutowireCapableBeanFactory 中實現，如下：

  1.    protected Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
  2.             throws BeanCreationException {
  4.         if (logger.isDebugEnabled()) {
  5.             logger.debug("Creating instance of bean '" + beanName + "'");
  6.         }
  7.         RootBeanDefinition mbdToUse = mbd;
  9.         // 確保此時的 bean 已經被解析了
  10.         // 如果獲取的class 屬性不為null，則克隆該 BeanDefinition
  11.         // 主要是因為該動態解析的 class 無法儲存到到共享的 BeanDefinition
  12.         Class> resolvedClass = resolveBeanClass(mbd, beanName);
  13.         if (resolvedClass != null && !mbd.hasBeanClass() && mbd.getBeanClassName() != null) {
  14.             mbdToUse = new RootBeanDefinition(mbd);
  15.             mbdToUse.setBeanClass(resolvedClass);
  16.         }
  18.         try {
  19.             // 驗證和準備改寫方法
  20.             mbdToUse.prepareMethodOverrides();
  21.         }
  22.         catch (BeanDefinitionValidationException ex) {
  23.             throw new BeanDefinitionStoreException(mbdToUse.getResourceDescription(),
  24.                     beanName, "Validation of method overrides failed", ex);
  25.         }
  27.         try {
  28.             // 給 BeanPostProcessors 一個機會用來傳回一個代理類而不是真正的類實體
  29.             // AOP 的功能就是基於這個地方
  30.             Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
  31.             if (bean != null) {
  32.                 return bean;
  33.             }
  34.         }
  35.         catch (Throwable ex) {
  36.             throw new BeanCreationException(mbdToUse.getResourceDescription(), beanName,
  37.                     "BeanPostProcessor before instantiation of bean failed", ex);
  38.         }
  40.         try {
  41.             // 執行真正建立 bean 的過程
  42.             Object beanInstance = doCreateBean(beanName, mbdToUse, args);
  43.             if (logger.isDebugEnabled()) {
  44.                 logger.debug("Finished creating instance of bean '" + beanName + "'");
  45.             }
  46.             return beanInstance;
  47.         }
  48.         catch (BeanCreationException | ImplicitlyAppearedSingletonException ex) {
  49.             throw ex;
  50.         }
  51.         catch (Throwable ex) {
  52.             throw new BeanCreationException(
  53.                     mbdToUse.getResourceDescription(), beanName, "Unexpected exception during bean creation", ex);
  54.         }
  55.     }

過程如下：

  • 解析指定 BeanDefinition 的 class

  • 處理 override 屬性

  • 實體化的前置處理

  • 建立 bean

解析指定 BeanDefinition 的 class

  1. Class> resolvedClass = resolveBeanClass(mbd, beanName)

這個方法主要是解析 bean definition 的 class 類，並將已經解析的 Class 儲存在 bean definition 中以供後面使用。如果解析的 class 不為空，則會將該 BeanDefinition 進行克隆至 mbdToUse，這樣做的主要目的是以為動態解析的 class 是無法儲存到共享的 BeanDefinition 中。

處理 override 屬性

大家還記得 lookup-method 和 replace-method 這兩個配置功能？在部落格 【死磕 Spring】----- IOC 之解析Bean：解析 bean 標簽（三） 中已經詳細分析了這兩個標簽的用法和解析過程，知道解析過程其實就是講這兩個配置存放在 BeanDefinition 中的 methodOverrides 屬性中，我們知道在 bean 實體化的過程中如果檢測到存在 methodOverrides，則會動態地位為當前 bean 生成代理並使用對應的攔截器為 bean 做增強處理。具體的實現我們後續分析，現在先看 mbdToUse.prepareMethodOverrides() 都幹了些什麼事，如下：

  1.     public void prepareMethodOverrides() throws BeanDefinitionValidationException {
  2.         if (hasMethodOverrides()) {
  3.             Set<MethodOverride> overrides = getMethodOverrides().getOverrides();
  4.             synchronized (overrides) {
  5.                 for (MethodOverride mo : overrides) {
  6.                     prepareMethodOverride(mo);
  7.                 }
  8.             }
  9.         }
  10.     }

如果存在 methodOverrides 則獲取所有的 override method ，然後透過迭代的方法一次呼叫 prepareMethodOverride() ，如下：

  1.     protected void prepareMethodOverride(MethodOverride mo) throws BeanDefinitionValidationException {
  2.         int count = ClassUtils.getMethodCountForName(getBeanClass(), mo.getMethodName());
  3.         if (count == 0) {
  4.             throw new BeanDefinitionValidationException(
  5.                     "Invalid method override: no method with name '" + mo.getMethodName() +
  6.                     "' on class [" + getBeanClassName() + "]");
  7.         }
  8.         else if (count == 1) {
  9.             mo.setOverloaded(false);
  10.         }
  11.     }

根據方法名稱從 class 中獲取該方法名的個數，如果為 0 則丟擲異常，如果 為 1 則設定該多載方法沒有被多載。若一個類中存在多個多載方法，則在方法呼叫的時候還需要根據引數型別來判斷到底多載的是哪個方法。在設定多載的時候其實這裡做了一個小小最佳化，那就是當 count==1 時，設定 overloaded=false，這樣表示該方法沒有多載，這樣在後續呼叫的時候便可以直接找到方法而不需要進行方法引數的校驗。

誠然，其實 mbdToUse.prepareMethodOverrides() 並沒有做什麼實質性的工作，只是對 methodOverrides 屬性做了一些簡單的校驗而已。

實體化的前置處理

resolveBeforeInstantiation() 的作用是給 BeanPostProcessors 後置處理器傳回一個代理物件的機會，其實在呼叫該方法之前 Spring 一直都沒有建立 bean ，那麼這裡傳回一個 bean 的代理類有什麼作用呢？作用體現在後面的 if 判斷：

  1. if (bean != null) {
  2.     return bean;
  3. }

如果代理物件不為空，則直接傳回代理物件，這一步驟有非常重要的作用，Spring 後續實現 AOP 就是基於這個地方判斷的。

  1.     protected Object resolveBeforeInstantiation(String beanName, RootBeanDefinition mbd) {
  2.         Object bean = null;
  3.         if (!Boolean.FALSE.equals(mbd.beforeInstantiationResolved)) {
  4.             if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
  5.                 Class> targetType = determineTargetType(beanName, mbd);
  6.                 if (targetType != null) {
  7.                     bean = applyBeanPostProcessorsBeforeInstantiation(targetType, beanName);
  8.                     if (bean != null) {
  9.                         bean = applyBeanPostProcessorsAfterInitialization(bean, beanName);
  10.                     }
  11.                 }
  12.             }
  13.             mbd.beforeInstantiationResolved = (bean != null);
  14.         }
  15.         return bean;
  16.     }

這個方法核心就在於 applyBeanPostProcessorsBeforeInstantiation() 和 applyBeanPostProcessorsAfterInitialization() 兩個方法，before 為實體化前的後處理器應用，after 為實體化後的後處理器應用，由於本文的主題是建立 bean，關於 Bean 的增強處理後續 LZ 會單獨出博文來做詳細說明。

建立 bean

如果沒有代理物件，就只能走常規的路線進行 bean 的建立了，該過程有 doCreateBean() 實現，如下：

  1.    protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
  2.             throws BeanCreationException {
  4.         // BeanWrapper是對Bean的包裝，其介面中所定義的功能很簡單包括設定獲取被包裝的物件，獲取被包裝bean的屬性描述器
  5.         BeanWrapper instanceWrapper = null;
  6.         // 單例模型，則從未完成的 FactoryBean 快取中刪除
  7.         if (mbd.isSingleton()) {anceWrapper = this.factoryBeanInstanceCache.remove(beanName);
  8.         }
  10.         // 使用合適的實體化策略來建立新的實體：工廠方法、建構式自動註入、簡單初始化
  11.         if (instanceWrapper == null) {
  12.             instanceWrapper = createBeanInstance(beanName, mbd, args);
  13.         }
  15.         // 包裝的實體物件
  16.         final Object bean = instanceWrapper.getWrappedInstance();
  17.         // 包裝的實體物件的型別
  18.         Class> beanType = instanceWrapper.getWrappedClass();
  19.         if (beanType != NullBean.class) {
  20.             mbd.resolvedTargetType = beanType;
  21.         }
  23.         // 檢測是否有後置處理
  24.         // 如果有後置處理，則允許後置處理修改 BeanDefinition
  25.         synchronized (mbd.postProcessingLock) {
  26.             if (!mbd.postProcessed) {
  27.                 try {
  28.                     // applyMergedBeanDefinitionPostProcessors
  29.                     // 後置處理修改 BeanDefinition
  30.                     applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
  31.                 }
  32.                 catch (Throwable ex) {
  33.                     throw new BeanCreationException(mbd.getResourceDescription(), beanName,
  34.                             "Post-processing of merged bean definition failed", ex);
  35.                 }
  36.                 mbd.postProcessed = true;
  37.             }
  38.         }
  40.         // 解決單例樣式的迴圈依賴
  41.         // 單例樣式 & 執行迴圈依賴&當前單例 bean 是否正在被建立
  42.         boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
  43.                 isSingletonCurrentlyInCreation(beanName));
  44.         if (earlySingletonExposure) {
  45.             if (logger.isDebugEnabled()) {
  46.                 logger.debug("Eagerly caching bean '" + beanName +
  47.                         "' to allow for resolving potential circular references");
  48.             }
  49.             // 提前將建立的 bean 實體加入到ectFactory 中
  50.             // 這裡是為了後期避免迴圈依賴
  51.             addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
  52.         }
  54.         /*
  55.          * 開始初始化 bean 實體物件
  56.          */
  57.         Object exposedObject = bean;
  58.         try {
  59.             // 對 bean 進行填充，將各個屬性值註入，其中，可能存在依賴於其他 bean 的屬性
  60.             // 則會遞迴初始依賴 bean
  61.             populateBean(beanName, mbd, instanceWrapper);
  62.             // 呼叫初始化方法
  63.             exposedObject = initializeBean(beanName, exposedObject, mbd);
  64.         }
  65.         catch (Throwable ex) {
  66.             if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {
  67.                 throw (BeanCreationException) ex;
  68.             }
  69.             else {
  70.                 throw new BeanCreationException(
  71.                         mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);
  72.             }
  73.         }
  75.         /**
  76.          * 迴圈依賴處理
  77.          */
  78.         if (earlySingletonExposure) {
  79.             // 獲取 earlySingletonReference
  80.             Object earlySingletonReference = getSingleton(beanName, false);
  81.             // 只有在存在迴圈依賴的情況下，earlySingletonReference 才不會為空
  82.             if (earlySingletonReference != null) {
  83.                 // 如果 exposedObject 沒有在初始化方法中被改變，也就是沒有被增強
  84.                 if (exposedObject == bean) {
  85.                     exposedObject = earlySingletonReference;
  86.                 }
  87.                 // 處理依賴
  88.                 else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
  89.                     String[] dependentBeans = getDependentBeans(beanName);
  90.                     Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
  91.                     for (String dependentBean : dependentBeans) {
  92.                         if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
  93.                             actualDependentBeans.add(dependentBean);
  94.                         }
  95.                     }
  96.                     if (!actualDependentBeans.isEmpty()) {
  97.                         throw new BeanCurrentlyInCreationException(beanName,
  98.                                 "Bean with name '" + beanName + "' has been injected into other beans [" +
  99.                                         StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
  100.                                         "] in its raw version as part of a circular reference, but has eventually been " +
  101.                                         "wrapped. This means that said other beans do not use the final version of the " +
  102.                                         "bean. This is often the result of over-eager type matching - consider using " +
  103.                                         "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
  104.                     }
  105.                 }
  106.             }
  107.         }
  108.         try {
  109.             // 註冊 bean
  110.             registerDisposableBeanIfNecessary(beanName, bean, mbd);
  111.         }
  112.         catch (BeanDefinitionValidationException ex) {
  113.             throw new BeanCreationException(
  114.                     mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);
  115.         }
  117.         return exposedObject;
  118.     }

整體的思路：

  1. 如果是單例樣式，則清除 factoryBeanInstanceCache 快取，同時傳回 BeanWrapper 實體物件，當然如果存在。

  2. 如果快取中沒有 BeanWrapper 或者不是單例樣式，則呼叫 createBeanInstance() 實體化 bean，主要是將 BeanDefinition 轉換為 BeanWrapper

  • MergedBeanDefinitionPostProcessor 的應用

  • 單例樣式的迴圈依賴處理

  • 呼叫 populateBean() 進行屬性填充。將所有屬性填充至 bean 的實體中

  • 呼叫 initializeBean() 初始化 bean

  • 依賴檢查

  • 註冊 DisposableBean

doCreateBean() 完成 bean 的建立和初始化工作，內容太多，這裡就只列出整體思路，下文開始將該方法進行拆分進行詳細講解，分佈從以下幾個方面進行闡述：

  • createBeanInstance() 實體化 bean

  • populateBean() 屬性填充

  • 迴圈依賴的處理

  • initializeBean() 初始化 bean

往
期
精
彩

【死磕 Spring】----- IOC 之分析各 scope 的 bean 建立

【死磕 Spring】----- IOC 之開啟 bean 的載入

【死磕 Spring】----- IOC 之從單例快取中獲取單例 bean

【死磕 Spring】----- IOC 之parentBeanFactory 與依賴處理

【死磕 Spring】----- IOC 之 IOC 初始化總結

END


>>>>>> 加群交流技術 <<<<<<

贊(0)
標籤：

相關推薦

熱門標籤

iOS (11238)微軟 (4955)Linux (4274)安全 (4180)Python (4161)效能 (3165)運維 (2774)最佳化 (2419).NET (2262)Google (2136)機器學習 (1795)併發 (1613)分散式 (1559)叢集 (1240)SQL (1174)Mysql (1060)區塊鏈 (1017)Docker (977)微服務 (922)面試 (919)Apache (743)NLP (725)Redis (719)Android (668)Git (640)架構師 (632)Nginx (630)Facebook (599)JVM (595)爬蟲 (476)

熱門文章

分享創造快樂

© 2024 知識星球   網站地圖