SpringBoot自动配置底层原理(手撕@SpringBootApplication注解源码)

在这里插入图片描述
我们从主程序类的@SpringBootApplication注解开始讲起
首先我们点进@SpringBootApplication中:
在这里插入图片描述
看到它是由@Target、@Retention、@Documented、@Inherited四个元注解和@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan()三个注解组合成的注解;
元注解我们就不用多说了,接下来我将讲解@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan这三个注解。
我们先说两个简单的注解@SpringBootConfiguration、@ComponentScan注解,最后再说最核心也最麻烦的注解@EnableAutoConfiguration注解。

一.@SpringBootConfiguration

我们点进@SpringBootConfiguration中:
在这里插入图片描述
我们发现它是由元注解和@Configuration组成,也就是@Configuration注解,那@Configuration是什么呢,它就代表当前是一个配置类。
也就是说明我们的MainApplication主程序类也是一个配置类,只不过它是一个核心配置类。

二.@ComponentScan

@ComponentScan我们都知道它是一个包扫描注解,指定扫描哪些内容。

三.@EnableAutoConfiguration

来了来了,最重要的它终于来了。
言归正传,我们点进@EnableAutoConfiguration注解中:
在这里插入图片描述
发现它是由4个元注解和@AutoConfigurationPackage、@Import({AutoConfigurationImportSelector.class})注解组成。
我们先讲@AutoConfigurationPackage注解,然后再将@Import({AutoConfigurationImportSelector.class})导入的组件的作用。

1.@AutoConfigurationPackage

我们点进@AutoConfigurationPackage注解中:
在这里插入图片描述
发现它实际上也是@Import注解,导入的Registrar是什么呢,我们在点进去看一下:
在这里插入图片描述

发现它有两个方法,实际上Registrar是给容器中批量的注册组件,因为用import一个一个导入太麻烦了,所以写一段代码批量注册;
我们在第一个方法上打上断点,可以看看它到底注册了哪些组件:
在这里插入图片描述
这个方法有两个参数,如下:
在这里插入图片描述
其中AnnotationMetadata是注解的源信息,注解是指@AutoConfigurationPackage,注解的源信息表示这个注解标在哪,它的每一个属性值都是什么,这个注解是@SpringBootApplication里的注解,@SpringBootApplication标在MainApplication主程序类上,所以它实际上也是标在MainApplication主程序类上的。
我们可以在debug时打开metadata查看其信息:
在这里插入图片描述
发现它确实是在主程序类上,然后我们继续讲这个方法,这个方法在这里new了一个PackageImports:
在这里插入图片描述
相当于把我们的注解源信息拿到获取我们的包名,我们可以让它计算一下我们得到的包名是什么:
在这里插入图片描述
在这里插入图片描述
可以看到计算得到了MainApplication主程序类所在的包路径。
我们接着说那个方法,它得到我们的包路径之后,也就是得到了主程序类的包名,然后把这个包名封装到一个数组里面,然后给我们注册到容器中。
也就是说我们的Registrar相当于是把某个包下的所有组件批量的注册进容器中。
@AutoConfigurationPackage小总结:

  • 利用Registrar给容器中导入一系列组件
  • 将MainApplication主程序类所在包下的所有组件导入进来

2.@Import({AutoConfigurationImportSelector.class})

利用selector再来给容器中批量的导入一些组件
我们点进AutoConfigurationImportSelector中:
在这里插入图片描述
我们的selectImports方法返回的数组规定了给容器中要导入哪些组件,而在selectImports方法中又调用了getAutoConfigurationEntry方法,所以呢,我们现在来研究getAutoConfigurationEntry方法,进入getAutoConfigurationEntry方法,给getAutoConfigurationEntry方法体打上断点:
在这里插入图片描述
debug运行,当我们逐条语句运行到获取configurations之后,可以看到configurations有130条:
在这里插入图片描述
点开configurations会发现有130个全类名,说明这130个全类名指定的组件全部是要导入到我们的容器中去的:
在这里插入图片描述
那我们怎么知道这130个是这样子的呢?我们给这个getCandidateConfigurations方法打一个断点,重新debug:
在这里插入图片描述
进入该方法内部,发现它实际上是用Spring的这些工厂加载器来加载一些东西:
在这里插入图片描述
点进SpringFactoriesLoader.loadFactoryNames:
在这里插入图片描述
再点入(List)loadSpringFactories(classLoaderToUse):
在这里插入图片描述
最终利用该方法给我们加载得到所有组件,那从哪里加载得到所有组件呢?
我们给loadSpringFactories方法体打上一个断点,重新debug:
在这里插入图片描述
可以看到它在这里加载了一个资源文件,位置为:META-INF/spring.factories
也就是说默认扫描我们当前系统里面所有META-INF/spring.factories位置的文件;
现在我们看spring-boot-autoconfigure-2.4.1.jar包下的META-INF:
在这里插入图片描述

发现它有spring.factories文件:
在这里插入图片描述
查看其文件内容,其中有一个配置项,org.springframework.boot.autoconfigure.EnableAutoConfiguration:
在这里插入图片描述
从22行到151行整整130行内容:
在这里插入图片描述
这就是我们的130个需要加载的组件,它们全部都在这里,而且全部都在这个配置文件里写死了,也就是说文件里面写死了spring-boot一启动就要给容器中加载的所有配置类。

但是现实情况是这个样子的吗,是真的要把130个组件全部加载进容器中吗?
实际上不是的,我们的SpringBoot有按需开启自动配置项的功能。
虽然我们130个场景的所有自动配置启动的时候默认全部加载。xxxxAutoConfiguration,但是最终会按需配置,按照条件装配规则(@Conditional)。
例如我们点进去AopAutoConfiguration中:
在这里插入图片描述

在这里插入图片描述

在这个类中,我们没有导入org.aspectj.weaver中的Advice这个类,所以其内部类AspectJAutoProxyingConfiguratio不会生效:
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/MrYushiwen/article/details/112095242