您好!
欢迎来到京东云开发者社区
登录
首页
博文
课程
大赛
工具
用户中心
开源
首页
博文
课程
大赛
工具
开源
更多
用户中心
开发者社区
>
博文
>
Spring竟然可以创建“重复”名称的bean?—一次项目中存在多个bean名称重复问题的排查
分享
打开微信扫码分享
点击前往QQ分享
点击前往微博分享
点击复制链接
Spring竟然可以创建“重复”名称的bean?—一次项目中存在多个bean名称重复问题的排查
RyanHan
2023-06-19
IP归属:北京
12800浏览
## 一、项目中存在了名称重复的bean 众所周知,在Spring中时不能够创建两个名称相同的bean的,否则会在启动时报错: ![image-20230322100944642](https://s2.loli.net/2023/03/22/DTi5jtv26Xhx3kA.png) 但是我却在我们的spring项目中发现了两个相同名称的`bean`,并且项目也可以正常启动,对应的bean也可以正常使用。 因为项目原因中会用到多个redis集群,所以有配置了多个redis环境,并且在id上做了区分。 但是在配置redis环境的时候,两个环境`bean`的`id`却是相同的。 ```xml <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](https://s2.loli.net/2023/03/22/TtLjEFuPmZks2nc.png) 可以看到我们创建的bean是正常的,并且从功能上来说也是可以使用的。 ## 二、问题的排查过程 ### 2.1 尝试直接找到创建重复bean位置 首先debug尝试找到创建重复bean时的相关信息,看看有没有什么思路 ![image-20230322103624912](https://s2.loli.net/2023/03/22/F5zqCN2pQ3AcgHO.png) 然后重启项目,选择debug模式,但是在运行之后IDEA提示断点被跳过了 ![image-20230322104033613](https://s2.loli.net/2023/03/22/uSHs41gxIeAO82f.png) 查阅了一些资料跟方式都不起作用,遂放弃此思路。 ### 2.2 从创建其父bean开始寻找思路 放弃了上述思路后想到,可以凭借之前学习的spring源码从代码层面去排查此问题 将断点设置到创建reids bean处 ![image-20230322104714244](https://s2.loli.net/2023/03/22/dxsUKB3qom8ZNRL.png) 果然,断点在这里是能进来的 ![image-20230322104804469](https://s2.loli.net/2023/03/22/enB7PKqEl9Hj4Tr.png) 那么我们的思路就很简单了。 在spring中,**装配属性**的步骤发生在:`populateBean(beanName, mbd, instanceWrapper)`的过程中,如果发现其属性也是一个bean,那么会先获取bean,如果不存在则会先创建其属性bean,然后创建完成之后将属性bean赋值给要装配的bean。 ```java //循环要装配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](https://s2.loli.net/2023/03/22/Yap1uT4DtzfxJOB.png) 我们从真正创建要装配的bean的地方开始找找什么时候开始创建bean的 ```java 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](https://s2.loli.net/2023/03/22/A6J2PxGRW9yI3eB.png) 从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](https://s2.loli.net/2023/03/22/RSO3E5TANXfk8YD.png) 其实答案已经很明显了: **如果我们创建的是一个普通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的用法 还是我们刚刚的例子,我们可以将其改写成下面的这个样子: ```xml <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的名称就不可重复。
上一篇:Spring源码核心剖析
下一篇:规则引擎调研及初步使用
RyanHan
文章数
15
阅读量
52378
作者其他文章
01
三十分钟入门基础Go——Java小子版
本篇文章适用于学习过其他面向对象语言(Java、Php),但没有学过Go语言的初学者。文章主要从Go与Java功能上的对比来阐述Go语言的基础语法、面向对象编程、并发与错误四个方面。
01
Dubbo源码浅析(一)—RPC框架与Dubbo
RPC,Remote Procedure Call 即远程过程调用,与之相对的是本地服务调用,即LPC(Local Procedure Call)。
01
0源码基础学习Spring源码系列(一)——Bean注入流程
通过本文,读者可以0源码基础的初步学习spring源码,并能够举一反三从此进入源码世界的大门!
01
Dubbo源码浅析(二)—SPI机制
SPI (Service Provider Interface),是一种将服务接口与服务实现实现分离的机制,以达到解耦的目的,大大提高了项目的可拓展性。
RyanHan
文章数
15
阅读量
52378
作者其他文章
01
三十分钟入门基础Go——Java小子版
01
Dubbo源码浅析(一)—RPC框架与Dubbo
01
0源码基础学习Spring源码系列(一)——Bean注入流程
01
Dubbo源码浅析(二)—SPI机制
添加企业微信
获取1V1专业服务
扫码关注
京东云开发者公众号