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，作者：Mr.Yushiwen，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/MrYushiwen/article/details/112095242