Spring Boot自动装配原理
# 前言
我相信，只要你用过Spring Boot，就会对这样一个现象非常的好奇：
引入一个组件依赖，加个配置，这个组件就生效了。
举个例子来说，比如我们常用的Redis, 在Spring Boot中的使用方式是这样的：
# 1. 引入依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
# 2. 编写配置
spring:
redis:
database: 0
timeout: 5000ms
host: 127.0.0.1
port: 6379
password: 123456
好了，接下来只需要使用时注入RedisTemplate就能使用了，像这样：
@Autowired private RedisTemplate redisTemplate;
这期间，我们做了什么嘛？我们什么也没有做，那么，这个RedisTemplate对象是怎么注入到Spring容器中的呢？
接下来，就让我们带着这样的疑问逐步剖析其中的原理，这个原理就叫做自动装配。
# SPI机制-服务提供者接口
SPI ，全称为 Service Provider Interface(服务提供者接口)，是一种服务发现机制。它通过在classpath路径下的META-INF/services文件夹查找文件，自动加载文件中所定义的类。
参考：https://segmentfault.com/a/1190000040510401
# SpringBoot自动装配
既然Springboot尽管这么好用，但是作为一个使用者，我们还是比较好奇它是怎么帮我们实现开箱即用的。Spring Boot有一个全局配置文件：application.properties或application.yml。在这个全局文件里面可以配置各种各样的参数比如你想改个端口啦server.port 或者想调整下日志的级别啦通通都可以配置。
这么多属性，这些属性在项目是怎么起作用的呢？SpringBoot项目看下来啥配置也没有，配置”（application.properties或application.yml除外），既 然从配置上面找不到突破口，那么我们就只能从启动类上面找入口了。启动类也就一个光秃秃的一个main方法，类上面仅有一个注SpringBootApplication这个注解是Spring Boot项目必不可少的注解。那么自动配置原理一定和这个注解有着千丝万缕的联系！我们下面来一起看看这个注解吧。「@SpringBootApplication注解」
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
这里最上面四个注解的话没啥好说的，基本上自己实现过自定义注解的话，都知道分别是什么意思。
@SpringBootConfiguration继承自@Configuration，二者功能也一致，标注当前类是配置类。@ComponentScan用于类或接口上主要是指定扫描路径，跟Xml里面的``配置一样。springboot如果不写这个扫描路径的话，默认就是启动类的路径。@EnableAutoConfiguration
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@AutoConfigurationPackage
@Import(AutoConfigurationImportSelector.class)
public @interface EnableAutoConfiguration {
这个注解我们重点看下AutoConfigurationImportSelector这个类getCandidateConfigurations这个方法里面通过SpringFactoriesLoader.loadFactoryNames()扫描所有具有META-INF/spring.factories的jar包（ spring.factories 我们可以理解成 Spring Boot 自己的 SPI 机制）。spring-boot-autoconfigure-x.x.x.x.jar里就有一个spring.factories文件。spring.factories文件由一组一组的Key = value的形式，其中一个key是EnableAutoConfiguration类的全类名，而它的value是一个以AutoConfiguration结尾的类名的列表，有redis、mq等这些类名以逗号分隔。
我们在回到getAutoConfigurationEntry这个方法当执行完getCandidateConfigurations这个方法的时候我们可以看到此时总共加载了127个自动配置类。
这些类难道都要加载进去吗？springboot还是没有那么傻的，它提倡的话是按需加载。
- 它会去掉重复的类
- 过滤掉我们配置了
exclude注解的类下面配置就会过滤掉RestTemplateAutoConfiguration这个类 - 经过上面的处理，剩下的这些自动配置的类如果要起作用的话，是需要满足一定的条件的。这些条件的满足的话
spring boot是通过条件注解来实现的。
❝@ConditionalOnBean：当容器里有指定Bean的条件下 @ConditionalOnClass：当类路径下有指定的类的条件下 @ConditionalOnExpression：基于SpEL表达式为true的时候作为判断条件才去实例化 @ConditionalOnJava：基于JVM版本作为判断条件 @ConditionalOnJndi：在JNDI存在的条件下查找指定的位置 @ConditionalOnMissingBean：当容器里没有指定Bean的情况下 @ConditionalOnMissingClass：当容器里没有指定类的情况下 @ConditionalOnWebApplication：当前项目是Web项目的条件下 @ConditionalOnNotWebApplication：当前项目不是Web项目的条件下 @ConditionalOnProperty：指定的属性是否有指定的值 @ConditionalOnResource：类路径是否有指定的值 @ConditionalOnOnSingleCandidate：当指定Bean在容器中只有一个，或者有多个但是指定首选的Bean ❞
这些注解都组合了@Conditional注解，只是使用了不同的条件组合最后为true时才会去实例化需要实例化的类，否则忽略过滤掉。我们在回到代码可以看到经过了条件判断过滤后我们剩下符合条件的自动配置类只剩23个了。其他的都是因为不满足条件注解而被过滤了。
如果我们想知道哪些自动配置类被过滤了，是由于什么原因被过滤了，以及加载了哪些类等。spring boot都为我们记录了日志。
这里就截取了部分日志。总共分别有下面四部分日志：
Positive matches：@Conditional条件为真，配置类被Spring容器加载。Negative matches:@Conditional条件为假，配置类未被Spring容器加载。Exclusions：我们明确了不需要加载的类。比如在上面启动类配置的RestTemplateAutoConfiguration类Unconditional classes：自动配置类不包含任何类级别的条件，也就是说，类始终会被自动加载。
# 自动配置生效
我们以ServletWebServerFactoryAutoConfiguration配置类为例，解释一下全局配置文件中的属性如何生效，比如：server.port=88，是如何生效的（当然不配置也会有默认值，这个默认值来自于org.apache.catalina.startup.Tomcat）。
// 标记为配置类
@Configuration(proxyBeanMethods = false)
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
// 如果有ServletRequest.class 才会生效
@ConditionalOnClass(ServletRequest.class)
@ConditionalOnWebApplication(type = Type.SERVLET)
// 把@ConfigurationProperties注解的类注入为Spring容器的Bean。
@EnableConfigurationProperties(ServerProperties.class)
@Import({ ServletWebServerFactoryAutoConfiguration.BeanPostProcessorsRegistrar.class,
ServletWebServerFactoryConfiguration.EmbeddedTomcat.class,
ServletWebServerFactoryConfiguration.EmbeddedJetty.class,
ServletWebServerFactoryConfiguration.EmbeddedUndertow.class })
public class ServletWebServerFactoryAutoConfiguration {
我们可以发现EnableConfigurationProperties注解里面配置的ServerProperties.class
@ConfigurationProperties(prefix = "server", ignoreUnknownFields = true)
public class ServerProperties {
/**
* Server HTTP port.
*/
private Integer port;
在这个类上有一个注解：@ConfigurationProperties，它的作用就是从配置文件中绑定属性到对应的bean上(也就是把我们application.properties对应的server.port映射到ServerProperties 类中的port属性)而@EnableConfigurationProperties这个注解就是把已经绑定了属性的bean（ServerProperties）注入到spring容器中（相当于@Component注解一样）。所有在配置文件中能配置的属性都是在xxxxPropertites类中封装着，配置文件能配置什么就可以参照某个功能对应的这个属性类。到现在为止应该能回答文章开头的那个问题了，面试的时候应该不需要回答的这么详细可以参考下以下答案：
Spring Boot启动的时候会通过@EnableAutoConfiguration注解找到META-INF/spring.factories配置文件中的所有自动配置类，并对其进行加载，而这些自动配置类都是以AutoConfiguration结尾来命名的，它实际上就是一个JavaConfig形式的Spring容器配置类，它能通过以Properties结尾命名的类中取得在全局配置文件中配置的属性如：server.port，而XxxxProperties类是通过@ConfigurationProperties注解与全局配置文件中对应的属性进行绑定的。
# 总结
SpringBoot启动会加载大量的自动配置类（通过“SPI”的方式），然后会根据条件注解保留一些需要的类。- 我们新引入一个组件，可以先看看springBoot是否已经有默认的提供。
SpringBoot基本实现了“零配置“，并且开箱即用。