Spring的@Bean只能放在@Configuration里面吗？

迈不过友情╰ 2021-06-22 15:38 310阅读 0赞

首先来看几个问题：

**- 1.@Bean方法只能定义在@Configuration里面吗？**

**- 2.@Bean方法定义在@Configuration里面和定义在@Component里面有啥区别？**

**- 3.@Bean方法可以是private static的吗？**

**- 4.@Bean方法啥时候必须得定义成static的？**

先说一下答案：只要是@Component注解修饰的类里面都可以定义@Bean，并且都可以注册到Spring容器里面。其实不仅仅是@Component，只要是被@Component修饰的注解同样也可以定义@Bean，比如：@Repository、@Service、@Controller @Configuration，甚至是接口的default方法上的@Bean也可以被扫描加入到Spring容器里面，下面我们就来证明下：

public interface IService {
         /**接口里面定义了@Bean*/  @Bean  default IService defaultService(){
           return new DefaultService();  }}//这是DefaultServicepublic class DefaultService implements IService{
       }//这是一个具体的实现类，被@Component修饰@Componentpublic class ServiceImpl implements IService  {
       }//这是配置类@Configuration@ComponentScan//启用了组件扫描public class DemoApp {
       }//这是入口类public static void main(String[] args) {
         AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(DemoApp.class);  //这个肯定没问题  IService impl = ctx.getBean(ServiceImpl.class);  System.out.println(impl);  //这里也能正常输出  IService iService = (IService)ctx.getBean("defaultService");  System.out.println(iService);}

以上代码说明，Spring在做组件扫描的时候，会沿着继承链，一直向上查找链路上的所有的@Bean，包括了接口。

既然@Component中可以定义@Bean，那跟在@Configuration里面定义的@Bean有啥区别的？

还是先看一段代码：

//这是Service1public class Service1 {
         public Service1(){
           System.out.println("construct s1:" + this);  }}//这是Service2, 构造函数注入了Service1public class Service2 {
         private Service1 s1;  public Service2(Service1 s1){
           this.s1 = s1;    System.out.println("construct s2:"+this);  }}//这是配置类，这里用@Bean把Service1和Service2注入到容器@Configuration@ComponentScanpublic class DemoConfiguration {
         @Bean  public Service1 service1(){
           return new Service1();  }  @Bean  public Service2 service2(){
           //注意这里的构造函数注入的方式，直接调用service1()方法    return new Service2(service1());  }}//搞个测试类public static void main(String[] args) {
         AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(DemoConfiguration.class);}输出结果：construct s1:com.github.xjs.iocdemo.AtConfiguration.Service1@1d548a08construct s2:com.github.xjs.iocdemo.AtConfiguration.Service2@50a7bc6e

以上代码可以看出来，虽然在service2()内部调用了service1(),但是却并不会生成2个Service1对象，因为Spring里面的Bean默认是单例的，如果生成2个对象就自相矛盾了。那Spring是如何做到调用了service1()到那时却又不生成对象的呢？显然，这里面用到了AOP技术。

那我们来看下如果是用@Component来定义bean会是什么样子呢？

继续添加代码：

//添加@Component类@Componentpublic class DemoComponent {
         //这里面同样定义了2个类，Service3和Service4  @Bean  public Service3 service3(){
           return new Service3();  }  @Bean  public Service4 service4(){
           return new Service4(service3());  }}//Service3跟Service1一模一样public class Service3 {
         public Service3(){
           System.out.println("construct s3:" + this);  }}//Service4跟Service2一模一样public class Service4 {
         private Service3 s3;  public Service4(Service3 s3){
           this.s3 = s3;    System.out.println("construct s4:"+this);  }}

因为DemoConfiguration已经开启了@ComponentScan，所以DemoComponent会被扫描到，因此Service3和Service4也可以被添加到容器里面，现在再来测试下：

public static void main(String[] args) {
         AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(DemoConfiguration.class);  DemoConfiguration demoConfig = ctx.getBean(DemoConfiguration.class);  System.out.println(demoConfig);  DemoComponent demoComponent = ctx.getBean(DemoComponent.class);  System.out.println(demoComponent);}//输出结果如下：construct s3:com.github.xjs.iocdemo.AtConfiguration.Service3@527e5409construct s3:com.github.xjs.iocdemo.AtConfiguration.Service3@1198b989construct s4:com.github.xjs.iocdemo.AtConfiguration.Service4@7ff95560construct s1:com.github.xjs.iocdemo.AtConfiguration.Service1@7d3a22a9construct s2:com.github.xjs.iocdemo.AtConfiguration.Service2@2a32de6ccom.github.xjs.iocdemo.AtConfiguration.DemoConfiguration$$EnhancerBySpringCGLIB$$51627097@4e91d63fcom.github.xjs.iocdemo.AtConfiguration.DemoComponent@d4342c2

以上可以看出来，Service3被创建了2个实例，而Service1只被创建了一个实例，同时，DemoConfiguration实际是用cglib生成了它的一个代理类，而DemoComponent就是普通的new出来的一个bean，因此，在DemoComponent里面的@Bean之间的引用只是普通的方法调用，而DemoConfiguration里面的@Bean之间的引用却是使用AOP做了增强。基于这个原因，@Configuration里面的@Bean方法一定不要定义成final、private、static的，虽然不会报错，但是没法生成代理（这样就跟@Component一样了），但是，@Component里面的@Bean就没有那么多限制了，比如：

public class Service5 {
       }@Componentpublic class DemoComponent {
         //注意这里的方法修饰符：private static final  @Bean  private static final Service5 service5(){
           return new Service5();  }}public static void main(String[] args) {
         //这里可以正常获取到Service5  Service5 s5 = ctx.getBean(Service5.class);  System.out.println(s5);}

那啥时候@Bean必须得定义成static的呢？定义成static以后，@Bean就跟定义它的@Configuration之间没啥关系了，就可以在创建@Configuration类之前把@Bean创建出来，如果需要在@Bean中返回BeanFactoryPostProcessor或者是BeanPostProcessor的时候，就必须得定义成static了，否则@Configuration里面的@Autowired之类的就失效了，因为@Configuration类本身是由BeanPostProcessor来处理的，举个例子看下：

//这是@Configuration配置类@Configuration@ComponentScanpublic class DemoConfiguration {
         /**@Bean返回了一个BeanFactoryPostProcessor*/  @Bean  public BeanFactoryPostProcessor beanFactoryPostProcessor(){
           return new DemoBeanFactoryPostProcessor();  }  /**Configuration类定义了@PostConstruct*/  @PostConstruct  public void postConstruct(){
           System.out.println(">>>>>>>DemoConfiguration#postConstruct");  }}//这是BeanFactoryPostProcessor，实际上啥也没干public class DemoBeanFactoryPostProcessor implements BeanFactoryPostProcessor {
         @Override  public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException{
         }}

运行的时候，发现@PostConstruct并不会生效，同时控制台会打印：

@Bean method DemoConfiguration.beanFactoryPostProcessor is non-static and returns an object assignable to Spring's BeanFactoryPostProcessor interface. This will result in a failure to process annotations such as @Autowired, @Resource and @PostConstruct within the method's declaring @Configuration class. Add the 'static' modifier to this method to avoid these container lifecycle issues;

如果把@Bean方法改成static，则可以成功打印输出。

结论：

The @Bean methods in a regular Spring component are processed differently than their counterparts inside a Spring @Configuration class. The difference is that @Component classes are not enhanced with CGLIB to intercept the invocation of methods and fields. CGLIB proxying is the means by which invoking methods or fields within @Bean methods in @Configuration classes creates bean metadata references to collaborating objects. Such methods are not invoked with normal Java semantics but rather go through the container in order to provide the usual lifecycle management and proxying of Spring beans, even when referring to other beans through programmatic calls to @Bean methods. In contrast, invoking a method or field in a @Bean method within a plain @Component class has standard Java semantics, with no special CGLIB processing or other constraints applying.

测试代码下载：https://github.com/xjs1919/enumdemo下面的configuration-demo。