乐趣区

关于spring:Configuration注解一定要加吗

在上一期 SpringBoot 自定义 starter 中,咱们讲到主动配置类是能够不加 @Configuration 注解的,然而在特定的场景会引发一个小小的问题,明天咱们就来聊一下这个奇怪的小常识吧

案例

先定义两个 Bean, 其中 Foo 依赖Boo

public class Bar {public Bar(){System.out.println("init");
    }
}
public class Foo {public Foo(Bar bar){}}

配置类

@Configuration
public class FooConfig {

    @Bean
    public Foo foo(){return new Foo(bar());
    }

    @Bean
    public Bar bar(){return new Bar();
    }
}

问题

配置类中有个写法:new Foo(bar()),置信大家也这样写过,然而不晓得大家有没有思考过这样一个问题:

Spring 外面的 Bean 默认都是单例的,没错吧?

那么请问 new Bar() 这一行代码在程序启动时执行了几次?

发现问题了吗?

失常来说,应该是有两次

一:将 bar 注入到容器中时调用一次

二:将 foo 注入容器中时调用到 bar() 办法,又调用一次new Bar()

那此时将会产生一个血案,Spring 容器中的 bar 对象与 foo 持有的 bar 对象不是同一个实例!

剖析到这,感觉是 1 次的小伙伴扣 1,2 次的小伙伴扣 2

答案

那咱们都能发现这个问题,Spring 的开发者必定也能想到,所以到底是几次呢?咱们来运行一下看看吧

每次运行 new Bar() 就会调用一次 Bar 对象的结构器,输入 init 语句

编写测试类

public class Main {public static void main(String[] args) {new AnnotationConfigApplicationContext(FooConfig.class);
    }
}

后果:

嘿,答案是一次,这要是 B 站我不得来一句 ” 猜对的小伙伴把不愧是我打在公屏上 ”

那么如果把 Configuration 注解去掉呢?

再来一把

!!!啊这 ….

此时 Bar 对象竟然被实例化了两次,血案产生了!

没错,这就我在结尾跟大家说的,如果不加 @Configuration 注解在某些特订的场景会引发一个小问题,这个特定的场景就是:在 @Bean 注解润饰的办法中调用了另一个 @Bean 注解润饰的办法。

思考

到这里,文章题目的问题曾经答复大家了,@Configuration注解能够不加,然而会呈现问题。

然而,有时候 Spring 倡议你不要加!就是在我说的没有特定的场景的时候。为什么呢?

这就须要大家思考一下,按失常的逻辑,Bar 对象必定是要被实例化两次的,然而为什么加了 @Configuration 注解后只实例化了一次呢?Spring 到底做了什么?

摸索

咱们关上 @Configuraiton 注解,外面有这样的一个属性proxyBeanMethods,默认值为 ture,Spring 对它的形容是这样的:

指定 @Bean 办法是否应该被代理,以便执行 Bean 生命周期行为,例如,即便在用户代码中间接调用 @Bean 办法的状况下,也要返回共享的单子 Bean 实例。这个性能须要办法拦挡,通过运行时生成的 CGLIB 子类来实现。

默认状况下是 true,容许通过配置类内的办法进行调用。如果不须要这样做,因为这个特定配置的每个 @Bean 办法都是自成一体的,被设计成供容器应用的一般工厂办法,那么将这个标记切换为 false,以防止 CGLIB 子类解决。
敞开 bean 办法拦挡能够无效地解决 @Bean 办法。它在行为上等同于移除 @Configuration。

所以当咱们加上 @Configuraiton 注解时,最初 Spring 其实应用的是一个 CGLIB 代理类

什么是 CGLIB 动静代理

CGLIB 是一个功能强大的高性能代码生成库。它是 JDK 动静代理的补充,因为它提供了不实现接口的代理类(通过继承)。

案例

还是方才的例子,这里再增加一个 CGLIB 的应用样例

public class Test {public static void main(String[] args) {Enhancer enhancer = new Enhancer();
    // 设置继承的父类
        enhancer.setSuperclass(FooConfig.class);
    // 设置拦挡的办法
        enhancer.setCallback((MethodInterceptor) (obj, method, args1, methodProxy) -> {
            // 调用父类办法前打印一行日志
      System.out.println("cglib proxy!");
            return methodProxy.invokeSuper(obj, args1);
        });
        final FooConfig fooConfig = (FooConfig) enhancer.create();
        fooConfig.bar();}
}

运行

Spring 中的实现形式

Spring 中的实现形式同样体现在它的回调办法中,它的回调办法还是有些简单的,我这里只摘出它的逻辑局部

@Override
@Nullable
public Object intercept(Object enhancedConfigInstance, Method beanMethod, Object[] beanMethodArgs,
                        MethodProxy cglibMethodProxy) throws Throwable {
  // 取出 BeanFactory
  ConfigurableBeanFactory beanFactory = getBeanFactory(enhancedConfigInstance);
  // 通过 beanMethod 确定 beanName
  String beanName = BeanAnnotationHelper.determineBeanNameFor(beanMethod);
  // 以后执行的办法是否与 beanMethod 雷同, 如果正在执行 foo,当在 foo 中调用到 bar 时则会返回 false
  if (isCurrentlyInvokedFactoryMethod(beanMethod)) {
    // 调用父类办法
    return cglibMethodProxy.invokeSuper(enhancedConfigInstance, beanMethodArgs);
  }
  // 间接从容器中取出 Bean
  return resolveBeanReference(beanMethod, beanMethodArgs, beanFactory, beanName);
}

这里贴出源码地址:ConfigurationClassEnhancer.BeanMethodInterceptor#intercept

感兴趣的小伙伴能够本人钻研下细节

小结

明天和小伙伴们聊了一下 @Configuration 的必要性,以及一点点它的原理,心愿大家有所播种~,咱们下期再见~

想要理解更多精彩内容,欢送关注公众号:程序员阿鉴

集体博客空间:https://zijiancode.cn

退出移动版