Spring竟然可以創建“重復”名稱的bean？—一次專案中存在多個bean名稱重復問題的排查-有解無憂

作者：京東科技韓國凱

一、專案中存在了名稱重復的bean

眾所周知，在Spring中時不能夠創建兩個名稱相同的bean的，否則會在啟動時報錯：

但是我卻在我們的spring專案中發現了兩個相同名稱的bean，并且專案也可以正常啟動，對應的bean也可以正常使用，

因為專案原因中會用到多個redis集群，所以有配置了多個redis環境，并且在id上做了區分，

但是在配置redis環境的時候，兩個環境bean的id卻是相同的，

<bean id="cacheClusterConfigProvider" >
    <property name="providers">
        <list>
            //創建了一個名為 ccProvider 的bean
            <bean id="ccProvider" >
                <!--# 替換為當前環境的R2M 3C配置中心地址（詳見上方R2M 3C服務地址）-->
                <property name="address" value="https://www.cnblogs.com/Jcloud/p/${r2m.zkConnection}"/>
                <!--# 替換為R2M集群名-->
                <property name="appName" value="https://www.cnblogs.com/Jcloud/p/${r2m.appName}"/>
                <!--# 替換為當前環境的客戶端對應配置中心token口令（參考上方token獲取方式）-->
                <property name="token" value="https://www.cnblogs.com/Jcloud/p/${r2m.token}"/>
                <!--# 替換為集群認證密碼-->
                <property name="password" value="https://www.cnblogs.com/Jcloud/p/${r2m.password}"/>
            </bean>
        </list>
    </property>
</bean>

<bean id="tjCacheClusterConfigProvider" >
    <property name="providers">
        <list>
            //這里竟然也是 ccProvider 
            <bean id="ccProvider" >
                <!--# 替換為當前環境的R2M 3C配置中心地址（詳見上方R2M 3C服務地址）-->
                <property name="address" value="https://www.cnblogs.com/Jcloud/p/${r2m.tj.zkConnection}"/>
                <!--# 替換為R2M集群名-->
                <property name="appName" value="https://www.cnblogs.com/Jcloud/p/${r2m.tj.appName}"/>
                <!--# 替換為當前環境的客戶端對應配置中心token口令（參考上方token獲取方式）-->
                <property name="token" value="https://www.cnblogs.com/Jcloud/p/${r2m.tj.token}"/>
                <!--# 替換為集群認證密碼-->
                <property name="password" value="https://www.cnblogs.com/Jcloud/p/${r2m.tj.password}"/>
            </bean>
        </list>
    </property>
</bean>

大家也都知道，<bean>標簽可以宣告一個bean，是肯定會被spring決議并且使用的，那么為什么在這里面兩個相同的bean名稱卻不會報錯呢？

可以看到我們創建的bean是正常的，并且從功能上來說也是可以使用的，

二、問題的排查程序

2.1 嘗試直接找到創建重復bean位置

首先debug嘗試找到創建重復bean時的相關資訊，看看有沒有什么思路

然后重啟專案，選擇debug模式，但是在運行之后IDEA提示斷點被跳過了

查閱了一些資料跟方式都不起作用，遂放棄此思路，

2.2 從創建其父bean開始尋找思路

放棄了上述思路后想到，可以憑借之前學習的spring原始碼從代碼層面去排查此問題

將斷點設定到創建reids bean處

果然，斷點在這里是能進來的

那么我們的思路就很簡單了，

在spring中，裝配屬性的步驟發生在：populateBean(beanName, mbd, instanceWrapper)的程序中，如果發現其屬性也是一個bean，那么會先獲取bean，如果不存在則會先創建其屬性bean，然后創建完成之后將屬性bean賦值給要裝配的bean，

//回圈要裝配bean的所有屬性
for (PropertyValue pv : original) {
   if (pv.isConverted()) {
      deepCopy.add(pv);
   }
   else {
      String propertyName = pv.getName();
      Object originalValue = https://www.cnblogs.com/Jcloud/p/pv.getValue();
      //獲取真正要裝配的bean
      Object resolvedValue = valueResolver.resolveValueIfNecessary(pv, originalValue);
      Object convertedValue = resolvedValue;
      boolean convertible = bw.isWritableProperty(propertyName) &&
            !PropertyAccessorUtils.isNestedOrIndexedProperty(propertyName);
   }
}

從debug中也可以看出，我們bean的屬性只有一個，也就是providers，符合我們在上面xml中配置的屬性

我們從真正創建要裝配的bean的地方開始找找什么時候開始創建bean的

private Object resolveInnerBean(Object argName, String innerBeanName, BeanDefinition innerBd) {
   RootBeanDefinition mbd = null;
   try {
      ...
      // 真正創建bean的地方
      Object innerBean = this.beanFactory.createBean(actualInnerBeanName, mbd, null);
      if (innerBean instanceof FactoryBean) {
         boolean synthetic = mbd.isSynthetic();
         return this.beanFactory.getObjectFromFactoryBean(
               (FactoryBean<?>) innerBean, actualInnerBeanName, !synthetic);
      }
      else {
         return innerBean;
      }
   }
   catch (BeansException ex) {
      throw new BeanCreationException(
            this.beanDefinition.getResourceDescription(), this.beanName,
            "Cannot create inner bean '" + innerBeanName + "' " +
            (mbd != null && mbd.getBeanClassName() != null ? "of type [" + mbd.getBeanClassName() + "] " : "") +
            "while setting " + argName, ex);
   }
}

createBean(actualInnerBeanName, mbd, null)這行代碼如果有小伙伴閱讀過spring原始碼一定不陌生，通過這個方法可以獲得要創建的bean物件，

從debug中也可以看到真正要創建的beanName已經換成了我們的想要裝配的屬性ccProvider

至此我們已經發現了，和我們的預期一致，<bean>標簽無論在什么位置確實會創建一個bean物件，

那么為什么這里的beanName不怕重復呢？

2.3 為什么這里的bean不會出現重復的問題

回顧剛剛之前提到的spring不允許重復名稱的bean，其實很好理解，因為我們在創建bean的程序中，會將創建好的bean以beanName為key放到快取的map中，如果我們有兩個相同名稱的bean，那么當存在重復的bean時，第二個bean會將第一個bean給覆寫掉，

這樣的話，就不存在唯一性了，別的bean需要依賴重復的bean的時候有可能回傳的并不是同一個bean，

那么為什么這里兩個bean并不會重復呢？

其實細心的讀者已經發現了，這里變數名稱是innerBean，說明他是一個內部bean，那么innerBean與普通的bean有什么不同呢？為什么innerBean并不會產生名稱重復的問題呢？

我們重新梳理下創建普通bean的流程：

innerbean.drawio

其實答案已經很明顯了：

如果我們創建的是一個普通bean，在創建完成之后會將bean放置到快取中，如果有其他bean要使用直接從快取中取走就可以了，而beanName不能重復也是基于此考慮，

而創建innerBean則基于createBean()原子性操作前提，只會回傳創建好的bean，并不會將其加入到spring的bean快取中，因此也就不存在beanName重復的問題了

三、總結

3.1 為什么spring可以存在”重復“名稱的bean

我們這里重新梳理下bean的創建流程：

在spring注入一個普通bean的程序中，會將通過反射創建的空屬性物件賦值，如果發現其依賴的屬性也是一個bean，那么會首先去獲取這個bean，如果獲取不到的話則會轉而去創建bean，

而此時要創建的bean成為innerBean，并不會被spring其他bean共享，所以可以在名稱上是重復的，

3.2 innerBean的用法

還是我們剛剛的例子，我們可以將其改寫成下面的這個樣子：

<bean id="cacheClusterConfigProvider" >
    <property name="providers">
        <list>
            <!--# 參考ccProviderRef-->
            <ref bean="ccProviderRef"></ref>
        </list>
    </property>
</bean>

<!--# 定義了一個公共的ccProviderRef-->
<bean id="ccProviderRef" >
    <!--# 替換為當前環境的R2M 3C配置中心地址（詳見上方R2M 3C服務地址）-->
    <property name="address" value="https://www.cnblogs.com/Jcloud/p/${r2m.zkConnection}"/>
    <!--# 替換為R2M集群名-->
    <property name="appName" value="https://www.cnblogs.com/Jcloud/p/${r2m.appName}"/>
    <!--# 替換為當前環境的客戶端對應配置中心token口令（參考上方token獲取方式）-->
    <property name="token" value="https://www.cnblogs.com/Jcloud/p/${r2m.token}"/>
    <!--# 替換為集群認證密碼-->
    <property name="password" value="https://www.cnblogs.com/Jcloud/p/${r2m.password}"/>
</bean>

在上面的例子中我們定義了一個普通bean，并將其參考到我們想要的屬性中，

此時ccProviderRef作為一個普通bean，是可以被其他bean參考的，但是此時bean的名稱就不可重復，

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/548400.html

標籤：Java

上一篇：基于OpenAI的代碼編輯器，有點酷有點強！

下一篇：Redis高頻40問

Spring竟然可以創建“重復”名稱的bean？—一次專案中存在多個bean名稱重復問題的排查

作者：京東科技 韓國凱