乐趣区

关于java:腾讯二面Bean-与-Component-用在同一个类上会怎么样

起源:cnblogs.com/youzhibing/p/15354706.html

疑虑背景

疑虑形容

最近,在进行开发的过程中,发现之前的一个写法,相似如下:

以我的了解,@Configuration 加 @Bean 会创立一个 userName 不为 null 的 UserManager 对象,而 @Component 也会创立一个 userName 为 null 的 UserManager 对象。

那么咱们在其余对象中注入 UserManager 对象时,到底注入的是哪个对象?

因为我的项目曾经上线了很长一段时间了,所以这种写法没有编译报错,运行也没有出问题。前面去找共事理解下,理论是想让:

失效,而理论也的确是它失效了。那么问题来了:Spring 容器中到底有几个 UserManager 类型的对象?

Spring Boot 版本

我的项目中用的 Spring Boot 版本是:2.0.3.RELEASE。对象的 scope 是默认值,也就是 singleton。

Spring Boot 根底就不介绍了,举荐下这个实战教程:

https://github.com/javastacks…

后果验证

验证形式有很多,能够 debug 跟源码,看看 Spring 容器中到底有几个 UserManager 对象,也能够间接从 UserManager 构造方法下手,看看哪几个构造方法被调用,等等。

咱们从构造方法下手,看看 UserManager 到底实例化了几次。

只有有参构造方法被调用了,无参构造方法岿然不动(基本没被调用)。如果想理解的更深一点,能够读读:Spring 的循环依赖,源码详细分析 → 真的非要三级缓存吗?

https://www.cnblogs.com/youzh…

既然 UserManager 构造方法只被调用了一次,那么后面的问题:到底注入的是哪个对象。答案也就清晰了,没得选了呀,只能是 @Configuration 加 @Bean 创立的 userName 不为 null 的 UserManager 对象。

问题又来了: 为什么不是 @Component 创立的 userName 为 null 的 UserManager 对象?

源码解析

@Configuration 与 @Component 关系很严密。

所以 @Configuration 可能被 component scan。

其中 ConfigurationClassPostProcessor 与 @Configuration 非亲非故,其类继承结构图如下:

它实现了 BeanFactoryPostProcessor 接口和 PriorityOrdered 接口。

对于 BeanFactoryPostProcessor,能够看看:

https://www.cnblogs.com/youzh…

从 AbstractApplicationContext 的 refresh 办法调用的 invokeBeanFactoryPostProcessors(beanFactory) 开始,来跟下源码。

此时实现了 com.lee.qsl 包下的 component scan,com.lee.qsl 包及子包下的 UserConfig、UserController 和 UserManager 都被扫描进去。留神,此刻 @Bean 的解决还未开始,UserManager 是通过 @Component 而被扫描进去的;此时 Spring 容器中 beanDefinitionMap 中的 UserManager 是这样的。

接下来一步很重要,与咱们想要的答案非亲非故。

循环递归解决 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]]

只是日志级别是 info,太不显眼了。

Spring 降级优化

可能 Spring 团队意识到了 info 级别太不显眼的问题,或者说意识到了间接笼罩的解决形式不太正当。所以在 Spring 5.1.2.RELEASE(Spring Boot 则是 2.1.0.RELEASE)做出了优化解决。

举荐一个 Spring Boot 基础教程及实战示例:

https://github.com/javastacks…

咱们来具体看看。

启动间接报错,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.

咱们来跟下源码,次要看看与 Spring 5.0.7.RELEASE 的区别。

新增了配置项 allowBeanDefinitionOverriding 来管制是否容许 BeanDefinition 笼罩,默认状况下是不容许的。咱们能够在配置文件中配置:spring.main.allow-bean-definition-overriding=true,容许 BeanDefinition 笼罩。这种解决形式是更优的,将选择权交给开发人员,而不是本人偷偷的解决,已达到开发者想要的成果。

总 结

Spring 5.0.7.RELEASE(Spring Boot 2.0.3.RELEASE)反对 @Configuration+ @Bean 与 @Component 同时作用于同一个类。启动时会给 info 级别的日志提醒,同时会将 @Configuration+@Bean 润饰的 BeanDefinition 笼罩掉 @Component 润饰的 BeanDefinition。

兴许 Spring 团队意识到了上述解决不太适合,于是在 Spring 5.1.2.RELEASE 做出了优化解决。减少了配置项:allowBeanDefinitionOverriding,将主动权交给了开发者,由开发者本人决定是否容许笼罩。

补充

对于 allowBeanDefinitionOverriding,后面有误,特意去翻了下源码,补充如下。Spring 1.2 引进 DefaultListableBeanFactory 的时候就有了 private boolean allowBeanDefinitionOverriding=true;,默认是容许 BeanDefinition 笼罩。

Spring4.1.2 引进 isAllowBeanDefinitionOverriding() 办法。

Spring 从头至尾默认都是容许 BeanDefinition 笼罩的,变的是 Spring Boot,Spring Boot 2.1.0 之前没有笼罩 Spring 的 allowBeanDefinitionOverriding 默认值,仍是容许 BeanDefinition 笼罩的。

Spring Boot 2.1.0 中 SpringApplication 定义了公有属性:allowBeanDefinitionOverriding。

没有显示的指定值,那么默认值就是 false,之后在 Spring Boot 启动过程中,会用此值笼罩掉 Spring 中的 allowBeanDefinitionOverriding 的默认值。

对于 allowBeanDefinitionOverriding,我想大家应该曾经分明了。

近期热文举荐:

1.1,000+ 道 Java 面试题及答案整顿 (2022 最新版)

2. 劲爆!Java 协程要来了。。。

3.Spring Boot 2.x 教程,太全了!

4. 别再写满屏的爆爆爆炸类了,试试装璜器模式,这才是优雅的形式!!

5.《Java 开发手册(嵩山版)》最新公布,速速下载!

感觉不错,别忘了顺手点赞 + 转发哦!

退出移动版