头图

作者:京东科技 韩国凯

一、项目中存在了名称重复的bean

众所周知,在Spring中时不能够创建两个名称相同的bean的,否则会在启动时报错:

image-20230322100944642

但是我却在我们的spring项目中发现了两个相同名称的bean,并且项目也可以正常启动,对应的bean也可以正常使用。

因为项目原因中会用到多个redis集群,所以有配置了多个redis环境,并且在id上做了区分。

但是在配置redis环境的时候,两个环境beanid却是相同的。

<bean id="cacheClusterConfigProvider" class="com.xxx.rediscluster.provider.CacheClusterConfigProvider">
    <property name="providers">
        <list>
            //创建了一个名为 ccProvider 的bean
            <bean id="ccProvider" class="com.xxx.rediscluster.provider.CCProvider">
                <!--# 替换为当前环境的R2M 3C配置中心地址(详见上方R2M 3C服务地址)-->
                <property name="address" value="${r2m.zkConnection}"/>
                <!--# 替换为R2M集群名-->
                <property name="appName" value="${r2m.appName}"/>
                <!--# 替换为当前环境的客户端对应配置中心token口令(参考上方token获取方式)-->
                <property name="token" value="${r2m.token}"/>
                <!--# 替换为集群认证密码-->
                <property name="password" value="${r2m.password}"/>
            </bean>
        </list>
    </property>
</bean>

<bean id="tjCacheClusterConfigProvider" class="com.xxx.rediscluster.provider.CacheClusterConfigProvider">
    <property name="providers">
        <list>
            //这里竟然也是 ccProvider 
            <bean id="ccProvider" class="com.xxx.rediscluster.provider.CCProvider">
                <!--# 替换为当前环境的R2M 3C配置中心地址(详见上方R2M 3C服务地址)-->
                <property name="address" value="${r2m.tj.zkConnection}"/>
                <!--# 替换为R2M集群名-->
                <property name="appName" value="${r2m.tj.appName}"/>
                <!--# 替换为当前环境的客户端对应配置中心token口令(参考上方token获取方式)-->
                <property name="token" value="${r2m.tj.token}"/>
                <!--# 替换为集群认证密码-->
                <property name="password" value="${r2m.tj.password}"/>
            </bean>
        </list>
    </property>
</bean>

大家也都知道,<bean>标签可以声明一个bean,是肯定会被spring解析并且使用的,那么为什么在这里面两个相同的bean名称却不会报错呢?

image-20230322103204708

可以看到我们创建的bean是正常的,并且从功能上来说也是可以使用的。

二、问题的排查过程

2.1 尝试直接找到创建重复bean位置

首先debug尝试找到创建重复bean时的相关信息,看看有没有什么思路

image-20230322103624912

然后重启项目,选择debug模式,但是在运行之后IDEA提示断点被跳过了

image-20230322104033613

查阅了一些资料跟方式都不起作用,遂放弃此思路。

2.2 从创建其父bean开始寻找思路

放弃了上述思路后想到,可以凭借之前学习的spring源码从代码层面去排查此问题

将断点设置到创建reids bean处

image-20230322104714244

果然,断点在这里是能进来的

image-20230322104804469

那么我们的思路就很简单了。

在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 = pv.getValue();
      //获取真正要装配的bean
      Object resolvedValue = valueResolver.resolveValueIfNecessary(pv, originalValue);
      Object convertedValue = resolvedValue;
      boolean convertible = bw.isWritableProperty(propertyName) &&
            !PropertyAccessorUtils.isNestedOrIndexedProperty(propertyName);
   }
}

从debug中也可以看出,我们bean的属性只有一个,也就是providers,符合我们在上面xml中配置的属性

image-20230322105338830

我们从真正创建要装配的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对象。

image-20230322152949119

从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" class="com.wangyin.rediscluster.provider.CacheClusterConfigProvider">
    <property name="providers">
        <list>
            <!--# 引用ccProviderRef-->
            <ref bean="ccProviderRef"></ref>
        </list>
    </property>
</bean>

<!--# 定义了一个公共的ccProviderRef-->
<bean id="ccProviderRef" class="com.wangyin.rediscluster.provider.CCProvider">
    <!--# 替换为当前环境的R2M 3C配置中心地址(详见上方R2M 3C服务地址)-->
    <property name="address" value="${r2m.zkConnection}"/>
    <!--# 替换为R2M集群名-->
    <property name="appName" value="${r2m.appName}"/>
    <!--# 替换为当前环境的客户端对应配置中心token口令(参考上方token获取方式)-->
    <property name="token" value="${r2m.token}"/>
    <!--# 替换为集群认证密码-->
    <property name="password" value="${r2m.password}"/>
</bean>

在上面的例子中我们定义了一个普通bean,并将其引用到我们想要的属性中。

此时ccProviderRef作为一个普通bean,是可以被其他bean引用的,但是此时bean的名称就不可重复。


京东云开发者
3.3k 声望5.4k 粉丝

京东云开发者(Developer of JD Technology)是京东云旗下为AI、云计算、IoT等相关领域开发者提供技术分享交流的平台。