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

1,002 阅读4分钟

一起养成写作习惯!这是我参与「掘金日新计划 · 4 月更文挑战」的第21天,点击查看活动详情

在这里插入图片描述

我们从主程序类的@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不会生效: 在这里插入图片描述