在上一期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
发表回复