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

Bertha 。 2023-10-06 21:58 5阅读 0赞

### 疑虑背景 ###

#### 疑虑描述 ####

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

![1ad429883047dd3424b96962467e0c7b.png][]

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

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

因为项目已经上线了很长一段时间了，所以这种写法没有编译报错，运行也没有出问题

后面去找同事了解下，实际是想让

![cd059ec45d0ae379e7619abb77145fc4.png][]

生效，而实际也确实是它生效了

那么问题来了：**Spring 容器中到底有几个 UserManager 类型的对象？**

#### Spring Boot 版本 ####

项目中用的 Spring Boot 版本是：`2.0.3.RELEASE`

对象的 scope 是默认值，也就是 singleton

### 结果验证 ###

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

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

![e98a059238f1a6c2c07d900e6ef99d52.gif][]

只有有参构造方法被调用了，无参构造方法岿然不动（根本没被调用）

既然 UserManager 构造方法只被调用了一次，那么前面的问题：到底注入的是哪个对象

答案也就清晰了，没得选了呀，只能是 `@Configuration` 加 `@Bean` 创建的 userName 不为 null 的 UserManager 对象

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

### 源码解析 ###

`@Configuration` 与 `@Component` 关系很紧密

![6554dc7579a735846287e218bec3b5ad.png][]

所以`@Configuration` 能够被 `component scan`

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

![863a7b77d142d593e4516c604c092bde.png][]

它实现了 `BeanFactoryPostProcessor` 接口和 `PriorityOrdered` 接口，关于 `BeanFactoryPostProcessor`，可以看看：

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

那么我们从 `AbstractApplicationContext` 的 refresh 方法调用的 `invokeBeanFactoryPostProcessors(beanFactory)`开始，来跟下源码

![fc553f3c5dec4df79d03b1b00df8935c.gif][]

此时完成了 `com.lee.qsl` 包下的 `component scan` ， `com.lee.qsl` 包及子包下的 UserConfig 、 UserController 和 UserManager 都被扫描出来

注意，此刻`@Bean` 的处理还未开始， UserManager 是通过`@Component` 而被扫描出来的；此时 Spring 容器中 `beanDefinitionMap` 中的 UserManager 是这样的

![e8b391c8446fa78e04deec58cf33619a.png][]

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

![5bb3aa9d58454c3ca3abc116aa4a1288.gif][]

![5bc1d62325576585b66f7a8a6c15cffe.png][]

循环递归处理 UserConfig 、 UserController 和 UserManager ，把它们都封装成 `ConfigurationClass` ，递归扫描 `BeanDefinition`

循环完之后，我们来看看 `configClasses`

![21c9d0c783985004afb23f97002ec879.gif][]

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

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

![3e14c6490a5c4ac5a3cb1db13a2e5794.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 ）做出了优化处理

我们来具体看看

![d0c6e7017124daed9a32924c65c45e0e.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` 的区别

![3a96d44dddea4651a6d227f0fee84158.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` 同时作用于同一个类

启动时会

### 疑虑背景 ###

#### 疑虑描述 ####

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

![c48e8d5644699e57c34c05ce43861714.png][]

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

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

因为项目已经上线了很长一段时间了，所以这种写法没有编译报错，运行也没有出问题

后面去找同事了解下，实际是想让

![d4c92b5e97baa986a044bb7d6bd0da00.png][]

生效，而实际也确实是它生效了

那么问题来了：**Spring 容器中到底有几个 UserManager 类型的对象？**

#### Spring Boot 版本 ####

项目中用的 Spring Boot 版本是：`2.0.3.RELEASE`

对象的 scope 是默认值，也就是 singleton

### 结果验证 ###

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

![1d4be37eb023009b6e8b3f3728dbc387.gif][]

只有有参构造方法被调用了，无参构造方法岿然不动（根本没被调用）

既然 UserManager 构造方法只被调用了一次，那么前面的问题：到底注入的是哪个对象

答案也就清晰了，没得选了呀，只能是 `@Configuration` 加 `@Bean` 创建的 userName 不为 null 的 UserManager 对象

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

### 源码解析 ###

`@Configuration` 与 `@Component` 关系很紧密

![e3c2a8310f22d93b1d26498b6da5a0b7.png][]

所以`@Configuration` 能够被 `component scan`

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

![12348e14c030675524d7c5c84c626663.png][]

它实现了 `BeanFactoryPostProcessor` 接口和 `PriorityOrdered` 接口，关于 `BeanFactoryPostProcessor`，可以看看：

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

那么我们从 `AbstractApplicationContext` 的 refresh 方法调用的 `invokeBeanFactoryPostProcessors(beanFactory)`开始，来跟下源码

![e064fe83887b4fb190f581b6f54beded.gif][]

此时完成了 `com.lee.qsl` 包下的 `component scan` ， `com.lee.qsl` 包及子包下的 UserConfig 、 UserController 和 UserManager 都被扫描出来

注意，此刻`@Bean` 的处理还未开始， UserManager 是通过`@Component` 而被扫描出来的；此时 Spring 容器中 `beanDefinitionMap` 中的 UserManager 是这样的

![e90c42a7cfe16ad1aebd63f6cd6d069c.png][]

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

![4c943b2cf4284d398a6eed4945345c60.gif][]

![b53ddf9a761738a13271454678bfaf8a.png][]

循环递归处理 UserConfig 、 UserController 和 UserManager ，把它们都封装成 `ConfigurationClass` ，递归扫描 `BeanDefinition`

循环完之后，我们来看看 `configClasses`

![856bcb213d3a8278cb03fa605e3c27c2.gif][]

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

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

![ee0d05daf74f4eb3b81a3abbefbb4a37.gif][]

是不是有什么发现？`@Component` 修饰的 UserManager 定义直接被覆盖成了 `@Configuration + @Bean` 修饰的 UserManager 定义

Bean 定义类型也由 `ScannedGenericBeanDefinition` 替换成了 `ConfigurationClassBeanDefinition`

后续通过 `BeanDefinition` 创建实例的时候，创建的自然就是 `@Configuration + @Bean` 修饰的 UserManager ，也就是会反射调用 UserManager 的有参构造方法

自此，答案也就清楚了

Spring 其实给出了提示

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

### Spring 升级优化 ###

可能 Spring 团队意识到了 info 级别太不显眼的问题，或者说意识到了直接覆盖的处理方式不太合理

所以在 `Spring 5.1.2.RELEASE` （Spring Boot 则是 2.1.0.RELEASE ）做出了优化处理

我们来具体看看

![28ee225a88617eaf3534f6a7ee40dd13.gif][]

启动直接报错，Spring 也给出了提示

我们来跟下源码，主要看看与 `Spring 5.0.7.RELEASE` 的区别

![0e0ed8b1865f47fba61dea7eab403014.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` 覆盖

![3c123aa7bb94cfcd3d162619e60ff919.png][]

Spring 4.1.2 引进了 `isAllowBeanDefinitionOverriding()`方法

![ffea9e4cdb6ef388525f92f57b6ff31a.png][]

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

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

![a0fc1ebd1fc92cd7510c2cb953263f77.png][]

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

![647a8fb9ec72410d9541d0f97d7ec289.gif][]

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

给 info 级别的日志提示，同时会将`@Configuration + @Bean` 修饰的 BeanDefinition 覆盖掉`@Component` 修饰的 BeanDefinition

也许 Spring 团队意识到了上述处理不太合适，于是在 `Spring 5.1.2.RELEASE` 做出了优化处理

增加了配置项：`allowBeanDefinitionOverriding` ，将主动权交给了开发者，由开发者自己决定是否允许覆盖

#### 补充 ####

关于 `allowBeanDefinitionOverriding` ，前面讲的不对，后面特意去翻了下源码，补充如下

Spring 1.2 引进 `DefaultListableBeanFactory` 的时候就有了 `private boolean allowBeanDefinitionOverriding = true;`，默认是允许 `BeanDefinition` 覆盖

![265a8e8bd3303534f3a60ff2aa7e3d48.png][]

Spring 4.1.2 引进了 `isAllowBeanDefinitionOverriding()`方法

![7351812f6af02ed02960484d747614fe.png][]

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

![b0a1610b25528b4a725ebfa48dc19bfc.png][]

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

![bc89c18da0d544fb896ea4cb6cc967ea.gif][] 文末福利  
 可以加小新老师vx免费获取【Java高清路线图】和【全套学习视频和配套资料】

![6b94f914013d478795b67c280a405df0.png][]

[1ad429883047dd3424b96962467e0c7b.png]: https://img-blog.csdnimg.cn/img_convert/1ad429883047dd3424b96962467e0c7b.png
[cd059ec45d0ae379e7619abb77145fc4.png]: https://img-blog.csdnimg.cn/img_convert/cd059ec45d0ae379e7619abb77145fc4.png
[e98a059238f1a6c2c07d900e6ef99d52.gif]: https://img-blog.csdnimg.cn/img_convert/e98a059238f1a6c2c07d900e6ef99d52.gif
[6554dc7579a735846287e218bec3b5ad.png]: https://img-blog.csdnimg.cn/img_convert/6554dc7579a735846287e218bec3b5ad.png
[863a7b77d142d593e4516c604c092bde.png]: https://img-blog.csdnimg.cn/img_convert/863a7b77d142d593e4516c604c092bde.png
[fc553f3c5dec4df79d03b1b00df8935c.gif]: https://img-blog.csdnimg.cn/fc553f3c5dec4df79d03b1b00df8935c.gif
[e8b391c8446fa78e04deec58cf33619a.png]: https://img-blog.csdnimg.cn/img_convert/e8b391c8446fa78e04deec58cf33619a.png
[5bb3aa9d58454c3ca3abc116aa4a1288.gif]: https://img-blog.csdnimg.cn/5bb3aa9d58454c3ca3abc116aa4a1288.gif
[5bc1d62325576585b66f7a8a6c15cffe.png]: https://img-blog.csdnimg.cn/img_convert/5bc1d62325576585b66f7a8a6c15cffe.png
[21c9d0c783985004afb23f97002ec879.gif]: https://img-blog.csdnimg.cn/img_convert/21c9d0c783985004afb23f97002ec879.gif
[3e14c6490a5c4ac5a3cb1db13a2e5794.gif]: https://img-blog.csdnimg.cn/3e14c6490a5c4ac5a3cb1db13a2e5794.gif
[d0c6e7017124daed9a32924c65c45e0e.gif]: https://img-blog.csdnimg.cn/img_convert/d0c6e7017124daed9a32924c65c45e0e.gif
[3a96d44dddea4651a6d227f0fee84158.gif]: https://img-blog.csdnimg.cn/3a96d44dddea4651a6d227f0fee84158.gif
[c48e8d5644699e57c34c05ce43861714.png]: https://img-blog.csdnimg.cn/img_convert/c48e8d5644699e57c34c05ce43861714.png
[d4c92b5e97baa986a044bb7d6bd0da00.png]: https://img-blog.csdnimg.cn/img_convert/d4c92b5e97baa986a044bb7d6bd0da00.png
[1d4be37eb023009b6e8b3f3728dbc387.gif]: https://img-blog.csdnimg.cn/img_convert/1d4be37eb023009b6e8b3f3728dbc387.gif
[e3c2a8310f22d93b1d26498b6da5a0b7.png]: https://img-blog.csdnimg.cn/img_convert/e3c2a8310f22d93b1d26498b6da5a0b7.png
[12348e14c030675524d7c5c84c626663.png]: https://img-blog.csdnimg.cn/img_convert/12348e14c030675524d7c5c84c626663.png
[e064fe83887b4fb190f581b6f54beded.gif]: https://img-blog.csdnimg.cn/e064fe83887b4fb190f581b6f54beded.gif
[e90c42a7cfe16ad1aebd63f6cd6d069c.png]: https://img-blog.csdnimg.cn/img_convert/e90c42a7cfe16ad1aebd63f6cd6d069c.png
[4c943b2cf4284d398a6eed4945345c60.gif]: https://img-blog.csdnimg.cn/4c943b2cf4284d398a6eed4945345c60.gif
[b53ddf9a761738a13271454678bfaf8a.png]: https://img-blog.csdnimg.cn/img_convert/b53ddf9a761738a13271454678bfaf8a.png
[856bcb213d3a8278cb03fa605e3c27c2.gif]: https://img-blog.csdnimg.cn/img_convert/856bcb213d3a8278cb03fa605e3c27c2.gif
[ee0d05daf74f4eb3b81a3abbefbb4a37.gif]: https://img-blog.csdnimg.cn/ee0d05daf74f4eb3b81a3abbefbb4a37.gif
[28ee225a88617eaf3534f6a7ee40dd13.gif]: https://img-blog.csdnimg.cn/img_convert/28ee225a88617eaf3534f6a7ee40dd13.gif
[0e0ed8b1865f47fba61dea7eab403014.gif]: https://img-blog.csdnimg.cn/0e0ed8b1865f47fba61dea7eab403014.gif
[3c123aa7bb94cfcd3d162619e60ff919.png]: https://img-blog.csdnimg.cn/img_convert/3c123aa7bb94cfcd3d162619e60ff919.png
[ffea9e4cdb6ef388525f92f57b6ff31a.png]: https://img-blog.csdnimg.cn/img_convert/ffea9e4cdb6ef388525f92f57b6ff31a.png
[a0fc1ebd1fc92cd7510c2cb953263f77.png]: https://img-blog.csdnimg.cn/img_convert/a0fc1ebd1fc92cd7510c2cb953263f77.png
[647a8fb9ec72410d9541d0f97d7ec289.gif]: https://img-blog.csdnimg.cn/647a8fb9ec72410d9541d0f97d7ec289.gif
[265a8e8bd3303534f3a60ff2aa7e3d48.png]: https://img-blog.csdnimg.cn/img_convert/265a8e8bd3303534f3a60ff2aa7e3d48.png
[7351812f6af02ed02960484d747614fe.png]: https://img-blog.csdnimg.cn/img_convert/7351812f6af02ed02960484d747614fe.png
[b0a1610b25528b4a725ebfa48dc19bfc.png]: https://img-blog.csdnimg.cn/img_convert/b0a1610b25528b4a725ebfa48dc19bfc.png
[bc89c18da0d544fb896ea4cb6cc967ea.gif]: https://img-blog.csdnimg.cn/bc89c18da0d544fb896ea4cb6cc967ea.gif
[6b94f914013d478795b67c280a405df0.png]: https://img-blog.csdnimg.cn/6b94f914013d478795b67c280a405df0.png