@Bean与@Component用在同一个类上，会怎么样？

柔情只为你懂 2024-03-27 18:20 2阅读 0赞

### **| 疑虑描述** ###

最近，在进行开发的过程中，发现之前的一个写法，类似如下：

![图片][58f1e3ea7d20846059ea87361b9ecf99.png]

以我的理解，@Configuration 加 @Bean 会创建一个 userName 不为 null 的 UserManager 对象，而 @Component 也会创建一个 userName 为 null 的 UserManager 对象。

**那么我们在其他对象中注入 UserManager 对象时，到底注入的是哪个对象？**

因为项目已经上线了很长一段时间了，所以这种写法没有编译报错，运行也没有出问题。后面去找同事了解下，实际是想让：

![图片][3de441b908be49ed73f5485e9058671a.png]

生效，而实际也确实是它生效了。那么问题来了：**Spring 容器中到底有几个 UserManager 类型的对象？**

#### **| Spring Boot 版本** ####

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

### **结果验证** ###

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

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

![图片][a5ebef8c9126c2de15ae702a4ffee9af.gif]

只有有参构造方法被调用了，无参构造方法岿然不动（根本没被调用）。如果想了解的更深一点，可以读读：Spring 的循环依赖，源码详细分析 → 真的非要三级缓存吗？

> https://www.cnblogs.com/youzhibing/p/14337244.html

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

问题又来了：**为什么不是 @Component 创建的 userName 为 null 的 UserManager** 对象？

### **源码解析** ###

@Configuration 与 @Component 关系很紧密。

![图片][ab5dc1d5483dfced21c8469f6fb86e26.png]

所以@Configuration能够被component scan。

其中 ConfigurationClassPostProcessor与@Configuration 息息相关，其类继承结构图如下：

![图片][087ac5e8c25704ada997a7bc42145971.png]

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

关于 BeanFactoryPostProcessor，可以看看：

> https://www.cnblogs.com/youzhibing/p/10559337.html

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

![图片][a035667739ba3bf0cd41b8f90a3b4517.gif]

此时完成了com.lee.qsl包下的component scan ，com.lee.qsl包及子包下的 UserConfig、UserController和UserManager都被扫描出来。注意，此刻@Bean的处理还未开始，UserManager是通过@Component而被扫描出来的；此时Spring容器中beanDefinitionMap中的 UserManager是这样的。

![图片][603c6dd8223cf260d9c8130232e08dfa.png]

接下来一步很重要，与我们想要的答案息息相关。

![图片][6c2ca7eb8e82f87f03bd4a25eeb45fcc.gif]

![图片][72bd1c3dda7a378dfa24def5d7c57258.png]

循环递归处理UserConfig 、UserController和UserManager，把它们都封装成 ConfigurationClass ，递归扫描 BeanDefinition。循环完之后，我们来看看 configClasses。

![图片][3700e7c1b970fd5117656c32a7c97114.gif]

UserConfig bean定义中beanMethods中有一个元素 \[BeanMethod:name=userManager,declaringClass=com.lee.qsl.config.UserConfig\]。

然后我们接着往下走，来仔细看看答案出现的环节。

![图片][83bfcbde52391a02aaf3b32537aa390b.gif]

是不是有什么发现？@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 ）做出了优化处理。

我们来具体看看。

![图片][21121edc3d249337c6d87ef7e1008e9b.gif]

启动直接报错，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的区别。

![图片][7c2c963bafaa071349693e98f7e15263.gif]

新增了配置项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覆盖。

![图片][be90a857de3a5625ce8eca72b857a783.png]

Spring4.1.2引进isAllowBeanDefinitionOverriding()方法。

![图片][4da8f5eb8ec29e519ceb8ada4e2f6f89.png]

Spring自始至终默认都是允许BeanDefinition覆盖的，变的是Spring Boot ，Spring Boot 2.1.0之前没有覆盖Spring 的allowBeanDefinitionOverriding默认值，仍是允许BeanDefinition覆盖的。

Spring Boot 2.1.0中SpringApplication定义了私有属性：allowBeanDefinitionOverriding。

![图片][66ccbaf7d4dbfa3406224632a02d9210.png]

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

![图片][0a135eac5b4081f4297dfb64510c1fa8.gif]

关于allowBeanDefinitionOverriding，我想大家应该已经清楚了。

[58f1e3ea7d20846059ea87361b9ecf99.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/b30db2a495a64efb9343ac41b1bc9b0b.png
[3de441b908be49ed73f5485e9058671a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/0d63be7cace543e9b890e9aa0a0dc1c7.png
[a5ebef8c9126c2de15ae702a4ffee9af.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/db44ed52d1e94695b1458132ae48df23.png
[ab5dc1d5483dfced21c8469f6fb86e26.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/ada79b6bc7bc4344be0034a02b16e4e2.png
[087ac5e8c25704ada997a7bc42145971.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/6e0a50374a5540a89310f1944deb09d9.png
[a035667739ba3bf0cd41b8f90a3b4517.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/835fb2d428cf46fab666098019d2d800.png
[603c6dd8223cf260d9c8130232e08dfa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/900af1722f6b42fe98d6e02b7efc7129.png
[6c2ca7eb8e82f87f03bd4a25eeb45fcc.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/4f8c0d04ef5d47509b5ee303e9df32fb.png
[72bd1c3dda7a378dfa24def5d7c57258.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/4c7162b1391d4c6bad789e8c4db217ae.png
[3700e7c1b970fd5117656c32a7c97114.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/30fd5df2a028459185d2346e5df3bf9e.png
[83bfcbde52391a02aaf3b32537aa390b.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/30b2d43f56d54aa39b003113c71e0412.png
[21121edc3d249337c6d87ef7e1008e9b.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/3fd77bb0b5f449c5a509b66bf93b5f8a.png
[7c2c963bafaa071349693e98f7e15263.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/b5a5984e2fd642d1a7d7bfa9079fc2cf.png
[be90a857de3a5625ce8eca72b857a783.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/cf66f7dfee054b35b232d0361e56b47b.png
[4da8f5eb8ec29e519ceb8ada4e2f6f89.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/77ca53a3e1154b79ad5b785c8e88c2cd.png
[66ccbaf7d4dbfa3406224632a02d9210.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/ff78c042c32c4e419ef40d4483e3b7be.png
[0a135eac5b4081f4297dfb64510c1fa8.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/11/412dbe9338404ee8884ce0428782d0a4.png