Spring竟然可以创建“重复”名称的bean?—一次项目中存在多个bean名称重复问题的排查
作者:京东科技 韩国凯
一、项目中存在了名称重复的bean
众所周知,在Spring中时不能够创建两个名称相同的bean的,否则会在启动时报错:
但是我却在我们的spring项目中发现了两个相同名称的bean
,并且项目也可以正常启动,对应的bean也可以正常使用。
因为项目原因中会用到多个redis集群,所以有配置了多个redis环境,并且在id上做了区分。
但是在配置redis环境的时候,两个环境bean
的id
却是相同的。
<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名称却不会报错呢?
可以看到我们创建的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 = 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
的流程:
其实答案已经很明显了:
如果我们创建的是一个普通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的名称就不可重复。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
开源月刊《HelloGitHub》第 84 期
兴趣是最好的老师,HelloGitHub 让你对编程感兴趣! 简介 HelloGitHub 分享 GitHub 上有趣、入门级的开源项目。 https://github.com/521xueweihan/HelloGitHub 这里有实战项目、入门教程、黑科技、开源书籍、大厂开源项目等,涵盖多种编程语言 Python、Java、Go、C/C++、Swift...让你在短时间内感受到开源的魅力,对编程产生兴趣! 以下为本期内容|每个月 28 号更新 C 项目 1、linked-list-good-taste:Linus Torvalds 解释编码品味的链表论证。在 2016 年的 TED 访谈中,Linus Torvalds 谈到了他认为好的编码品味,并举了一个例子:在单向链表中移除项目的两种实现。为了从链表中删除第一项,其中一个实现需要处理特殊情况,而另一个则不需要,Linus 更喜欢后者。 2、rpi4-osdev:为树莓派 4 编写操作系统的教程。这是一份 RealVNC 的 CTO 在树莓派 4 裸机上,编写操作系统的教程。内容分为 15 个章节,每章完成操作系统的一个部分,并提...
- 下一篇
聊聊前端性能指标那些事儿
作者:京东科技 郝梁 前言:作为 C 端前端研发,除了攻克业务难点以外,也要有更深层的自我目标,那就是性能优化。这事儿说大不大,说小也不小,但难度绝对不一般,所涉及的范围优化点深入工程每个细胞。做好前端性能优化绝非简单之事!文章主要内容介绍前端性能考核指标及优化方案。 一、前端性能指标有哪些? 根据 chrome Lighthouse 最新规则,前端性能指标考量主要有 FCP(First Contenful Paint)、SI(Speed Index)、LCP(Largest Contentful Paint)、TBT(Total Blocking Time)、CLS(Cumulative Layout Shift) ,占比分别如下。 二、什么是 FCP ? FCP: First Contentful Paint 首次内容绘制是指测量页面从开始加载到页面内容(文本、图片、背景图、svg 元素或非白色 canvas 元素)的任何部分在屏幕上完成渲染的时间,是测量加载速度感知的重要指标之一。 示例: 从上图可以观察到,页面加载开始到页面渲染完成的时间轴中,FCP 发生在第二帧...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Mario游戏-低调大师作品
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker快速安装Oracle11G,搭建oracle11g学习环境