Spring BeanDefinition 也分父子关系?
在 Spring 框架中,BeanDefinition 是一个核心概念,用于定义和配置 bean 的元数据,虽然在实际应用中,我们一般并不会或者很少直接定义 BeanDefinition,但是,我们在 XML 文件中所作的配置,以及利用 Java 代码做的各种 Spring 配置,都会被解析为 BeanDefinition,然后才会做进一步的处理。BeanDefinition 允许开发人员以一种声明性的方式定义和组织 bean,这里有很多属性,今天松哥单纯的来和小伙伴们聊一聊它的 parentName 属性,parentName 属性在 BeanDefinition 中扮演着重要的角色,用于建立 bean 之间的父子关系。
> 之前松哥有一篇文章和小伙伴们聊了 BeanFactory 之间的父子关系(Spring 中的父子容器是咋回事?),大家注意和今天的内容进行区分,今天我们聊的是 BeanDefinition 之间的父子关系。
BeanDefinition 的 parentName 属性的主要功能是允许我们在创建一个 bean 的同时,能够继承另一个已经定义好的 bean。通过指定 parentName 属性,我们可以重用已有 bean 的配置,并在此基础上进行修改或扩展。
先不废话了,我先来举两个例子,小伙伴们先感受一下 BeanDefinition 的作用。
1. 实践
假设我有如下两个类,首先是一个动物的基类,如下:
public class Animal { private String name; private Integer age; //省略 getter/setter }
然后有一个 Dog 类,如下:
public class Dog { private String name; private Integer age; private String color; //省略 getter/setter }
> 小伙伴们注意,这里的 Dog 类并没有继承自 Animal 类,但是有两个跟 Animal 同名的属性。之所以这样设计是希望小伙伴们理解 BeanDefinition 中的 parentName 属性和 Java 中的继承并无关系,虽然大部分情况下我们用到 parentName 的时候,Java 中相关的类都是继承关系。
现在,有一些通用的属性我想在 Animal 中进行配置,Dog 中特有的属性则在 Dog 中进行配置,我们来看下通过 XML 和 Java 分别该如何配置。
1.1 XML 配置
<bean id="animal" class="org.javaboy.demo.p2.Animal"> <property name="name" value="小黑" /> <property name="age" value="3" /> </bean> <bean class="org.javaboy.demo.p2.Dog" id="dog" parent="animal"> <property name="color" value="黑色" /> </bean>
小伙伴们看到,首先我们配置 Animal,Animal 中有 name 和 age 两个属性,然后我又配置了 Dog Bean,并未之指定了 parent 为 animal,然后给 Dog 设置了 color 属性。
现在,Dog Bean 定义出来的 BeanDefinition 中将来就包含了 animal 中的属性值。
1.2 Java 配置
再来看看 Java 配置该如何写。
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(); RootBeanDefinition pbd = new RootBeanDefinition(); MutablePropertyValues pValues = new MutablePropertyValues(); pValues.add("name", "小黄"); pbd.setBeanClass(Animal.class); pbd.setPropertyValues(pValues); GenericBeanDefinition cbd = new GenericBeanDefinition(); cbd.setBeanClass(Dog.class); cbd.setParentName("parent"); MutablePropertyValues cValues = new MutablePropertyValues(); cValues.add("name", "小强"); cbd.setPropertyValues(cValues); ctx.registerBeanDefinition("parent", pbd); ctx.registerBeanDefinition("child", cbd); ctx.refresh(); Dog child = (Dog) ctx.getBean("child"); System.out.println("child = " + child);
这里我使用了 RootBeanDefinition 来做 parent,其实从名字上就能看出来 RootBeanDefinition 适合做 parent,并且 RootBeanDefinition 不能作为 child。强行设置运行时会抛出异常,RootBeanDefinition#setParentName 方法如下:
@Override public void setParentName(@Nullable String parentName) { if (parentName != null) { throw new IllegalArgumentException("Root bean cannot be changed into a child bean with parent reference"); } }
MutablePropertyValues 是为相应的对象设置属性值。
child 我这里使用了 GenericBeanDefinition,这个主要是做 child 的处理,最早有一个专门做 child 的 ChildBeanDefinition,不过自从 Spring2.5 开始提供了 GenericBeanDefinition 之后,现在用来做 child 首选 GenericBeanDefinition。
在上述案例中,parent 和 child 都设置了 name 属性,那么 child 会覆盖掉 parent,这一点和 Java 中的继承一致。
用法就是这样,并不难。
这就是 Spring BeanDefinition 中的父子关系问题。
2. 源码分析
那么接下来我们也把这块的源码稍微来分析一下。
简便起见,我们就不从 Bean 的创建开始分析了,直接来看和 BeanDefinition 中 parentName 属性相关的地方,但是前面涉及到的方法还是给小伙伴们梳理一下,就是下图:
那么这里涉及到的关键方法其实就是 AbstractBeanFactory#getMergedBeanDefinition:
protected RootBeanDefinition getMergedBeanDefinition( String beanName, BeanDefinition bd, @Nullable BeanDefinition containingBd) throws BeanDefinitionStoreException { synchronized (this.mergedBeanDefinitions) { RootBeanDefinition mbd = null; RootBeanDefinition previous = null; // Check with full lock now in order to enforce the same merged instance. if (containingBd == null) { mbd = this.mergedBeanDefinitions.get(beanName); } if (mbd == null || mbd.stale) { previous = mbd; if (bd.getParentName() == null) { // Use copy of given root bean definition. if (bd instanceof RootBeanDefinition rootBeanDef) { mbd = rootBeanDef.cloneBeanDefinition(); } else { mbd = new RootBeanDefinition(bd); } } else { // Child bean definition: needs to be merged with parent. BeanDefinition pbd; try { String parentBeanName = transformedBeanName(bd.getParentName()); if (!beanName.equals(parentBeanName)) { pbd = getMergedBeanDefinition(parentBeanName); } else { if (getParentBeanFactory() instanceof ConfigurableBeanFactory parent) { pbd = parent.getMergedBeanDefinition(parentBeanName); } else { throw new NoSuchBeanDefinitionException(parentBeanName, "Parent name '" + parentBeanName + "' is equal to bean name '" + beanName + "': cannot be resolved without a ConfigurableBeanFactory parent"); } } } // Deep copy with overridden values. mbd = new RootBeanDefinition(pbd); mbd.overrideFrom(bd); } // Set default singleton scope, if not configured before. if (!StringUtils.hasLength(mbd.getScope())) { mbd.setScope(SCOPE_SINGLETON); } // A bean contained in a non-singleton bean cannot be a singleton itself. // Let's correct this on the fly here, since this might be the result of // parent-child merging for the outer bean, in which case the original inner bean // definition will not have inherited the merged outer bean's singleton status. if (containingBd != null && !containingBd.isSingleton() && mbd.isSingleton()) { mbd.setScope(containingBd.getScope()); } // Cache the merged bean definition for the time being // (it might still get re-merged later on in order to pick up metadata changes) if (containingBd == null && isCacheBeanMetadata()) { this.mergedBeanDefinitions.put(beanName, mbd); } } if (previous != null) { copyRelevantMergedBeanDefinitionCaches(previous, mbd); } return mbd; } }
这个方法看名字就是要获取一个合并之后的 BeanDefinition,就是将 child 中的属性和 parent 中的属性进行合并,然后返回,这个方法中有一个名为 mbd 的变量,这就是合并之后的结果。
- 首先会尝试从 mergedBeanDefinitions 变量中获取到合并之后的 BeanDefinition,mergedBeanDefinitions 相当于就是一个临时缓存,如果之前已经获取过了,那么获取成功之后就将之保存到 mergedBeanDefinitions 中,如果是第一次进入到该方法中,那么该变量中就没有我们需要的数据,所以会继续执行后面的步骤。
- 当第 1 步并未拿到 mbd 的时候,接下来继续判断
bd.getParentName()
是否为空,这个其实就是查看当前的 BeanDefinition 是否有设置 parentName,如果有设置,这里获取到的就不为 null,否则为 null。如果这里获取到的值为 null,那么就会根据当前传入的 BeanDefinition 生成一个 mbd,至于具体的生成方式:如果传入的 BeanDefinition 是 RootBeanDefinition 类型的,则调用 clone 方法去生成 mbd(本质上也是 new 一个新的 RootBeanDefinition),如果传入的 BeanDefinition 不是 RootBeanDefinition 类型的,则直接 new 一个新的 RootBeanDefinition,在 new 的过程中,会把传入的 BeanDefinition 上的属性都复制到新的 RootBeanDefinition 中。 - 如果
bd.getParentName()
不为空,则意味着存在 parent BeanDefinition,所以就要进行合并处理了,合并时候又有一个小细节,如果 parentBeanName 等于当前的 beanName,由于 Spring 在同一个容器中不允许存在同名的 bean,所以这就说明 parentBeanName 可能是父容器的 Bean,此时就要去父容器中去处理,当然最终调用到的还是当前方法,关于父子容器这一块,小伙伴们可以参考松哥之前的 Spring 中的父子容器是咋回事? 一文。如果 parentBeanName 不等于当前 beanName,那么现在就可以调用 getMergedBeanDefinition 方法去获取到 parentBeanDefinition 了,getMergedBeanDefinition 是当前方法的重载方法,该方法最终也会调用到当前方法,原因就在于 parentBeanDefinition 本身也可能存在 parentBeanDefinition。 - 有了 pbd 之后,接下来 new 一个 RootBeanDefinition,然后调用 overrideFrom 方法进行属性合并,合并的方式就是用传入的 BeanDefinition 中的属性去覆盖 pbd 中同名的属性。
- 最后就是再设置 scope 属性等,然后把 mbd 返回即可。
核心流程就是上面这个步骤,如此之后,拿到手的就是和 parent 合并之后的 BeanDefinition 了。
3. 小结
最后我们再来稍微总结下:
使用 parentName 属性的一个主要优势是提高代码的可维护性和重用性。当我们需要创建多个相似的 bean 时,可以通过定义一个基础 bean,并在其他 bean 中使用 parentName 属性来继承其配置。这样,我们只需在基础 bean 中定义一次配置,而不必为每个派生 bean 重复相同的配置。
另一个使用 parentName 属性的场景是在多个层次结构中定义 bean。假设我们有一个通用的基础服务层 bean,而不同的业务模块需要在此基础上进行扩展。通过使用 parentName 属性,我们可以为每个业务模块定义一个派生 bean,并在其中添加特定于模块的配置。这种层次结构的定义使得我们可以更好地组织和管理不同模块之间的 bean。
通过使用 parentName 属性,我们可以轻松地创建和管理 bean 的层次结构。这种继承关系使得我们可以更好地组织和重用 bean 的配置,减少了代码的冗余性。同时,它还提供了一种灵活的方式来定义不同模块之间的 bean,使得应用程序更易于扩展和维护。
综上所述,Spring 框架中的 BeanDefinition 的 parentName 属性允许我们在定义 bean 时建立父子关系,从而提高代码的可维护性和重用性。通过继承已有 bean 的配置,我们可以避免重复编写相似的配置,并更好地组织和管理不同层次结构的 bean。
有的小伙伴们可能会搞混今天内容和之前松哥所写的 Spring 父子容器之间的关系,小伙伴们参考这篇文章就清楚啦:Spring 中的父子容器是咋回事?。
另外,Spring BeanDefinition 中的 parentName 和 Java 中的继承虽然有点像,但是并不能同等看待,它们之间也还是有一些区别的:
- 概念和作用:Java 中的继承是一种面向对象的编程概念,用于定义类之间的父子关系,子类继承父类的属性和方法。而在 Spring 中,BeanDefinition 的 parentName 属性是用于定义 bean 之间的父子关系,一个派生 bean 可以继承另一个已定义的 bean 的配置。
- 语法和用法:在 Java 中,继承是通过使用关键字
extends
来实现的,子类通过继承父类来获得父类的属性和方法。而在 Spring 中,通过在 BeanDefinition 中配置 parentName 属性来指定一个 bean 的父 bean,从而继承父 bean 的配置。 - 范围和应用:Java 中的继承主要用于类的继承关系,用于定义类之间的层次结构和代码的重用。而在 Spring 中,BeanDefinition 的继承主要用于定义 bean 之间的配置继承关系,用于组织和管理 bean 的配置,提高代码的可维护性和重用性。
好啦,Spring BeanDefinition 中的 parentName 属性现在大家明白了吧~

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
【社区福利】OneOS 8月积分兑好礼!(开发板、双肩包...)
【OneOS积分兑换】 2023年8月积分兑换开始啦!上架的产品有F103开发板、定制双肩包、鼠标等丰富奖品,大家快来兑换吧~ 兑换时间:2023年即日起-8月31日 积分详情:看OneOS征文台账:https://kdocs.cn/l/cotjQiMFT2mS 兑换途径:加入OneOS QQ技术交流群(158631242),@OneOS运营小助手即可兑换 文章上传:文章上传专区后请填写文章收集问卷星:https://www.wjx.cn/vm/OtYYtlp.aspx# 可兑换礼品有限,先到先得哦!
- 下一篇
存算分离实践:构建轻量、云中立的大数据平台
今天我们将分享社区用户多点 DMALL 的案例。多点 DMALL 是亚洲领先的全渠道数字零售解决方案服务商,目前已与 380 家零售企业达成合作,覆盖 6 个国家和地区。 面对 B 端客户日益增长的企业数据,存算一体的架构显得力不从心。计算资源冗余浪费、所依靠的CDH发行版技术栈复杂、部署运维困难及计算资源潮汐现象严重等问题,迫使多点启动架构升级的进程。同时,为满足 B 端客户多样化的需求,多点需要构建一个可以在多云环境下更具性价比、可复用的大数据底层基座和平台工具链。基于此,多点的大数据团队开始搭建存算分离的云原生大数据架构。 本文深入剖析这次改造的架构设计与演进过程,分享多点 DMALL 在此过程中的经验和挑战。值得一提的是,他们利用 JuiceFS 社区版实现了与 Ranger 组件进行权限的对接,希望此经验能为其他使用 JuiceFS 的企业提供参考。 一、存算一体架构下的痛点和挑战 1.1 架构原生存在的痛点 存算一体架构带来的成本和运维挑战,是大部分企业在大数据发展中一定会面对的问题。 传统的 Hadoop 生态体系中,数据存储角色与计算角色通常会部署在相同的机器上,一个占...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2配置默认Tomcat设置,开启更多高级功能