@Bean与@Component用在同一个类上,会怎么样?
文章来源:https://sourl.cn/nN9qXE
疑虑背景
那么我们在其他对象中注入 UserManager 对象时,到底注入的是哪个对象?
因为项目已经上线了很长一段时间了,所以这种写法没有编译报错,运行也没有出问题。后面去找同事了解下,实际是想让:
生效,而实际也确实是它生效了。那么问题来了:Spring 容器中到底有几个 UserManager 类型的对象?
| Spring Boot 版本
项目中用的 Spring Boot 版本是:2.0.3.RELEASE。对象的 scope 是默认值,也就是 singleton。
结果验证
验证方式有很多,可以 debug 跟源码,看看 Spring 容器中到底有几个 UserManager 对象,也可以直接从 UserManager 构造方法下手,看看哪几个构造方法被调用,等等。
我们从构造方法下手,看看 UserManager 到底实例化了几次。
只有有参构造方法被调用了,无参构造方法岿然不动(根本没被调用)。如果想了解的更深一点,可以读读:Spring 的循环依赖,源码详细分析 → 真的非要三级缓存吗?
https://www.cnblogs.com/youzhibing/p/14337244.html
既然 UserManager 构造方法只被调用了一次,那么前面的问题:到底注入的是哪个对象。答案也就清晰了,没得选了呀,只能是 @Configuration 加 @Bean 创建的 userName 不为 null 的 UserManager 对象。
问题又来了:为什么不是 @Component 创建的 userName 为 null 的 UserManager 对象?
源码解析
@Configuration 与 @Component 关系很紧密。
所以@Configuration能够被component scan。
其中 ConfigurationClassPostProcessor与@Configuration 息息相关,其类继承结构图如下:
它实现了BeanFactoryPostProcessor接口和PriorityOrdered接口。
关于 BeanFactoryPostProcessor,可以看看:
https://www.cnblogs.com/youzhibing/p/10559337.html
从AbstractApplicationContext的refresh方法调用的invokeBeanFactoryPostProcessors(beanFactory)开始,来跟下源码。
接下来一步很重要,与我们想要的答案息息相关。
循环递归处理UserConfig 、UserController和UserManager,把它们都封装成 ConfigurationClass ,递归扫描 BeanDefinition。循环完之后,我们来看看 configClasses。
UserConfig bean定义中beanMethods中有一个元素 [BeanMethod:name=userManager,declaringClass=com.lee.qsl.config.UserConfig]。
然后我们接着往下走,来仔细看看答案出现的环节。
是不是有什么发现?@Component修饰的UserManager定义直接被覆盖成了@Configuration +@Bean修饰的UserManager定义。Bean定义类型也由ScannedGenericBeanDefinition替换成了ConfigurationClassBeanDefinition。
后续通过BeanDefinition创建实例的时候,创建的自然就是@Configuration+@Bean修饰的 UserManager,也就是会反射调用UserManager的有参构造方法。
自此,答案也就清楚了。Spring 其实给出了提示:
2021-10-03 20:37:33.697 INFO 13600 --- [
main] o.s.b.f.s.DefaultListableBeanFactory : Overriding bean definition for bean 'userManager' with a different definition: replacing [Generic bean: class [com.lee.qsl.manager.UserManager]; scope=singleton; abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodName=null; destroyMethodName=null; defined in file [D:\qsl-project\spring-boot-bean-component\target\classes\com\lee\qsl\manager\UserManager.class]] with [Root bean: class [null]; scope=; abstract=false; lazyInit=false; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=userConfig; factoryMethodName=userManager; initMethodName=null; destroyMethodName=(inferred); defined in class path resource [com/lee/qsl/config/UserConfig.class]]
Spring升级优化
可能Spring团队意识到了info级别太不显眼的问题,或者说意识到了直接覆盖的处理方式不太合理。所以在Spring 5.1.2.RELEASE (Spring Boot 则是 2.1.0.RELEASE )做出了优化处理。
我们来具体看看。
启动直接报错,Spring也给出了提示。
The bean 'userManager', defined in class path resource [com/lee/qsl/config/UserConfig.class], could not be registered. A bean with that name has already been defined in file [D:\qsl-project\spring-boot-bean-component\target\classes\com\lee\qsl\manager\UserManager.class] and overriding is disabled.
新增了配置项allowBeanDefinitionOverriding来控制是否允许BeanDefinition覆盖,默认情况下是不允许的。我们可以在配置文件中配置:spring.main.allow-bean-definition-overriding=true ,允许BeanDefinition覆盖。这种处理方式是更优的,将选择权交给开发人员,而不是自己偷偷的处理,已达到开发者想要的效果。
总 结
| 补充
关于allowBeanDefinitionOverriding,前面有误,特意去翻了下源码,补充如下。Spring 1.2引进DefaultListableBeanFactory的时候就有了private boolean allowBeanDefinitionOverriding=true;,默认是允许BeanDefinition覆盖。
Spring自始至终默认都是允许BeanDefinition覆盖的,变的是Spring Boot ,Spring Boot 2.1.0之前没有覆盖Spring 的allowBeanDefinitionOverriding默认值,仍是允许BeanDefinition覆盖的。
Spring Boot 2.1.0中SpringApplication定义了私有属性:allowBeanDefinitionOverriding。
关于allowBeanDefinitionOverriding,我想大家应该已经清楚了。
END
推荐阅读 一键生成Springboot & Vue项目!【毕设神器】
Java可视化编程工具系列(一)
Java可视化编程工具系列(二)
顺便给大家推荐一个GitHub项目,这个 GitHub 整理了上千本常用技术PDF,绝大部分核心的技术书籍都可以在这里找到,
GitHub地址:https://github.com/javadevbooks/books
电子书已经更新好了,你们需要的可以自行下载了,记得点一个star,持续更新中..