spring如何完成自动配置
⑴ SpringBoot核心原理：自动配置、事件驱动、Condition
SpringBoot是Spring的包装，通过自动配置使得SpringBoot可以做到开箱即用，上手成本非常低，但是学习其实现原理的成本大大增加，需要先了解熟悉Spring原理。
如果还不清楚Spring原理的，可以先查看博主之前的文章，本篇主要分析SpringBoot的启动、自动配置、Condition、事件驱动原理。
SpringBoot启动非常简单，因其内置了Tomcat，所以只需要通过下面几种方式启动即可：
可以看到第一种是最简单的，也是最常用的方式，需要注意类上面需要标注 @SpringBootApplication 注解，这是自动配置的核心实现，稍后分析，先来看看SpringBoot启动做了些什么？
在往下之前，不妨先猜测一下，run方法中需要做什么？对比Spring源码，我们知道，Spring的启动都会创建一个 ApplicationContext 的应用上下文对象，并调用其refresh方法启动容器，SpringBoot只是Spring的一层壳，肯定也避免不了这样的操作。
另一方面，以前通过Spring搭建的项目，都需要打成War包发布到Tomcat才行，而现在SpringBoot已经内置了Tomcat，只需要打成Jar包启动即可，所以在run方法中肯定也会创建对应的Tomcat对象并启动。以上只是我们的猜想，下面就来验证，进入run方法：
SpringBoot的启动流程就是这个方法，先看 getRunListeners 方法，这个方法就是去拿到所有的 SpringApplicationRunListener 实现类，这些类是用于SpringBoot事件发布的，关于事件驱动稍后分析，这里主要看这个方法的实现原理：
一步步追踪下去可以看到最终就是通过SPI机制根据接口类型从 META-INF/spring.factories 文件中加载对应的实现类并实例化，SpringBoot的自动配置也是这样实现的。
为什么要这样做呢？通过注解扫描不可以么？当然不行，这些类都在第三方jar包中，注解扫描实现是很麻烦的，当然你也可以通过 @Import 注解导入，但是这种方式不适合扩展类特别多的情况，所以这里采用SPI的优点就显而易见了。
回到run方法中，可以看到调用了 createApplicationContext 方法，见名知意，这个就是去创建应用上下文对象：
注意这里通过反射实例化了一个新的没见过的上下文对象 ，这个是SpringBoot扩展的，看看其构造方法：
如果你有看过Spring注解驱动的实现原理，这两个对象肯定不会陌生，一个实支持注解解析的，另外一个是扫描包用的。
上下文创建好了，下一步自然就是调用refresh方法启动容器：
这里首先会调用到其父类中 ：
可以看到是直接委托给了父类：
这个方法不会陌生吧，之前已经分析过了，这里不再赘述，至此SpringBoot的容器就启动了，但是Tomcat启动是在哪里呢？run方法中也没有看到。
实际上Tomcat的启动也是在refresh流程中，这个方法其中一步是调用了onRefresh方法，在Spring中这是一个没有实现的模板方法，而SpringBoot就通过这个方法完成了Tomcat的启动：
这里首先拿到 TomcatServletWebServerFactory 对象，通过该对象再去创建和启动Tomcat：
上面的每一步都可以对比Tomcat的配置文件，需要注意默认只支持了http协议：
如果想要扩展的话则可以对 additionalTomcatConnectors 属性设置值，需要注意这个属性没有对应的setter方法，只有 addAdditionalTomcatConnectors 方法，也就是说我们只能通过实现 BeanFactoryPostProcessor 接口的 postProcessBeanFactory 方法，而不能通过 的 方法，因为前者可以通过传入的BeanFactory对象提前获取到 TomcatServletWebServerFactory 对象调用 addAdditionalTomcatConnectors 即可；而后者只能拿到BeanDefinition对象，该对象只能通过setter方法设置值。
这段代码会在控制台打印所有的事件名称，按照顺序如下：
以上是正常启动关闭，如果发生异常还有发布 ApplicationFailedEvent 事件。事件的发布遍布在整个容器的启动关闭周期中，事件发布对象刚刚我们也看到了是通过SPI加载的 SpringApplicationRunListener 实现类 EventPublishingRunListener ，同样事件监听器也是在 spring.factories 文件中配置的，默认实现了以下监听器：
可以看到有用于文件编码的（ ），有加载日志框架的（ LoggingApplicationListener ），还有加载配置的（ ConfigFileApplicationListener ）等等一系列监听器，SpringBoot也就是通过这系列监听器将必要的配置和组件加载到容器中来，这里不再详细分析，感兴趣的读者可以通过其实现的 onApplicationEvent 方法看到每个监听器究竟是监听的哪一个事件，当然事件发布和监听我们自己也是可以扩展的。
SpringBoot最核心的还是自动配置，为什么它能做到开箱即用，不再需要我们手动使用 @EnableXXX 等注解来开启？这一切的答案就在 @SpringBootApplication 注解中：
这里重要的注解有三个： @SpringBootConfiguration 、 @EnableAutoConfiguration 、 @ComponentScan 。 @ComponentScan 就不用再说了， @SpringBootConfiguration 等同于 @Configuration ，而 @EnableAutoConfiguration 就是开启自动配置：
@AutoConfigurationPackage 注解的作用就是将该注解所标记类所在的包作为自动配置的包，简单看看就行，主要看 ，这个就是实现自动配置的核心类，注意这个类是实现的 DeferredImportSelector 接口。
在这个类中有一个 selectImports 方法。这个方法在我之前的文章这一次搞懂Spring事务注解的解析也有分析过，只是实现类不同，它同样会被 类调用，先来看这个方法做了些什么：
追踪源码最终可以看到也是从 META-INF/spring.factories 文件中拿到所有 EnableAutoConfiguration 对应的值（在 spring-boot-autoconfigure 中）并通过反射实例化，过滤后包装成 AutoConfigurationEntry 对象返回。
看到这里你应该会觉得自动配置的实现就是通过这个 selectImports 方法，但实际上这个方法通常并不会被调用到，而是会调用该类的内部类 AutoConfigurationGroup 的process和selectImports方法，前者同样是通过 getAutoConfigurationEntry 拿到所有的自动配置类，而后者这是过滤排序并包装后返回。
下面就来分析 是怎么调用到这里的，直接进入 processConfigBeanDefinitions 方法：
前面一大段主要是拿到合格的 Configuration 配置类，主要逻辑是在 ConfigurationClassParser.parse 方法中，该方法完成了对 @Component 、 @Bean 、 @Import 、 @ComponentScans 等注解的解析，这里主要看对 @Import 的解析，其它的读者可自行分析。一步步追踪，最终会进入到 processConfigurationClass 方法：
这里需要注意 this.conditionEvaluator.shouldSkip 方法的调用，这个方法就是进行Bean加载过滤的，即根据 @Condition 注解的匹配值判断是否加载该Bean，具体实现稍后分析，继续跟踪主流程 doProcessConfigurationClass ：
这里就是完成对一系列注解的支撑，我省略掉了，主要看 processImports 方法，这个方法就是处理 @Import 注解的：
刚刚我提醒过 是实现 DeferredImportSelector 接口的，如果不是该接口的实现类则是直接调用 selectImports 方法，反之则是调用 DeferredImportSelectorHandler.handle 方法：
首先创建了一个 DeferredImportSelectorHolder 对象，如果是第一次执行则是添加到 deferredImportSelectors 属性中，等到 ConfigurationClassParser.parse 的最后调用process方法：
反之则是直接执行，首先通过register拿到 AutoConfigurationGroup 对象：
然后在 processGroupImports 方法中进行真正的处理：
在 getImports 方法中就完成了对process和 selectImports 方法的调用，拿到自动配置类后再递归调用调用 processImports 方法完成对自动配置类的加载。至此，自动配置的加载过程就分析完了，下面是时序图：
在自动配置类中有很多Condition相关的注解，以AOP为例：
这里就能看到 @ConditionalOnProperty 、 @ConditionalOnClass 、 @ConditionalOnMissingClass ，另外还有 @ConditionalOnBean 、 @ConditionalOnMissingBean 等等很多条件匹配注解。
这些注解表示条件匹配才会加载该Bean，以 @ConditionalOnProperty 为例，表明配置文件中符合条件才会加载对应的Bean，prefix表示在配置文件中的前缀，name表示配置的名称， havingValue 表示配置为该值时才匹配， matchIfMissing 则是表示没有该配置是否默认加载对应的Bean。其它注解可类比理解记忆，下面主要来分析该注解的实现原理。
这里注解点进去看会发现每个注解上都标注了 @Conditional 注解，并且value值都对应一个类，比如 OnBeanCondition ，而这些类都实现了 Condition 接口，看看其继承体系：
上面只展示了几个实现类，但实际上Condition的实现类是非常多的，我们还可以自己实现该接口来扩展 @Condition 注解。Condition接口中有一个matches方法，这个方法返回true则表示匹配。该方法在 ConfigurationClassParser 中多处都有调用，也就是刚刚我提醒过的shouldSkip方法，具体实现是在 ConditionEvaluator 类中：
再来看看matches的实现，但 OnBeanCondition 类中没有实现该方法，而是在其父类 SpringBootCondition 中：
getMatchOutcome 方法也是一个模板方法，具体的匹配逻辑就在这个方法中实现，该方法返回的 ConditionOutcome 对象就包含了是否匹配和日志消息两个字段。进入到 OnBeanCondition 类中：
可以看到该类支持了 @ConditionalOnBean 、 @ConditionalOnSingleCandidate 、 @ConditionalOnMissingBean 注解，主要的匹配逻辑在 getMatchingBeans 方法中：
这里逻辑看起来比较复杂，但实际上就做了两件事，首先通过 getNamesOfBeansIgnoredByType 方法调用 beanFactory.getBeanNamesForType 拿到容器中对应的Bean实例，然后根据返回的结果判断哪些Bean存在，哪些Bean不存在（Condition注解中是可以配置多个值的）并返回MatchResult对象，而MatchResult中只要有一个Bean没有匹配上就返回false，也就决定了当前Bean是否需要实例化。
本篇分析了SpringBoot核心原理的实现，通过本篇相信读者也将能更加熟练地使用和扩展SpringBoot。
另外还有一些常用的组件我没有展开分析，如事务、MVC、监听器的自动配置，这些我们有了Spring源码基础的话下来看一下就明白了，这里就不赘述了。
最后读者可以思考一下我们应该如何自定义starter启动器，相信看完本篇应该难不倒你。
⑵ 如何使用Spring Boot的自动配置
第一步，编写配置Bean——PrintAfterInitBean
代码如下,因为只是一个简单例子，这里的配置Bean其实可以是其他任何复杂配置Bean，例如DataSource。往往一个公共包需要多个这样配置Bean才能完成其配置。
public class PrintAfterInitBean implements InitializingBean {
private String message;
public void afterPropertiesSet() throws Exception {
System.out.println(message);
}
//setter getter
}
第二步，创建一个AutoConfiguration。
如果搜索Spring Boot下面的类，你会发现其实有很多名字形如xxxAutoConfiguration的类，这些类都是Spirng Boot为我们做的一些快捷配置类。 创建一个TestAutoConfig，作为一个自动配置类
@Configuration
public class TestAutoConfig {
@Bean
@ConfigurationProperties(prefix = "init")
@ConditionalOnMissingBean(PrintAfterInitBean.class)
@ConditionalOnProperty(prefix = "init",value = "message")
public PrintAfterInitBean printAfterInitBean() {
return new PrintAfterInitBean();
}
}
@ConfigurationProperties 是Spring Boot提供的方便属性注入的注解，功能其实和@Value类似
@ConditionalOnMissingBean 表示当BeanFactory中没有PrintAfterInitBean类型的Bean才会创建，否则就会忽略这个Bean。这个就是上图中所谓的【满足自动配置条件】，同理的，ConditionalOnProperty表示当存在配置前缀为init，配置值为message的配置的时候，才会生效。@ConditionalOnXXX 系列的注解都是为了在自动配置中，不侵入用户的配置。
第三步，创建spring.factories
在resources下面创建META-INF/spring.factories, 然后在文件中把第二步的类配置进去
org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.netease.xxx.xxx.UrsPropertyAutoConfig
这样就完成一个Spring Boot自动配置，如果存在init.message的配置，那么spring boot启动的时候就会打印init.message配置对应值。
⑶ Spring自动装配原理
其中它主要是依赖一个父项目，主要是管理项目的资源过滤及插件！
点进去，发现还有一个父依赖
这里才是真正管理SpringBoot应用里面所有依赖版本的地方，SpringBoot的版本控制中心；
以后我们导入依赖默认是不需要写版本；但是如果导入的包没有在依赖中管理着就需要手动配置版本了；
springboot-boot-starter-xxx ：就是spring-boot的场景启动器
SpringBoot将所有的功能场景都抽取出来，做成一个个的starter （启动器），只需要在项目中引入这些starter即可，所有相关的依赖都会导入进来 ， 我们要用什么功能就导入什么样的场景启动器即可 ；我们未来也可以自己自定义 starter；
默认的主启动类
但是一个简单的启动类并不简单！我们来分析一下这些注解都干了什么
@SpringBootApplication
作用：标注在某个类上说明这个类是SpringBoot的主配置类 ， SpringBoot就应该运行这个类的main方法来启动SpringBoot应用；
进入这个注解：可以看到上面还有很多其他注解！
@ComponentScan
这个注解在Spring中很重要 ,它对应XML配置中的元素。
作用：自动扫描并加载符合条件的组件或者bean ， 将这个bean定义加载到IOC容器中
@SpringBootConfiguration
作用：SpringBoot的配置类 ，标注在某个类上 ， 表示这是一个SpringBoot的配置类；
我们继续进去这个注解查看
这里的 @Configuration，说明这是一个配置类 ，配置类就是对应Spring的xml 配置文件；
里面的 @Component 这就说明，启动类本身也是Spring中的一个组件而已，负责启动应用！
我们回到 SpringBootApplication 注解中继续看。
@EnableAutoConfiguration ：开启自动配置功能
以前我们需要自己配置的东西，而现在SpringBoot可以自动帮我们配置 ；@EnableAutoConfiguration告诉SpringBoot开启自动配置功能，这样自动配置才能生效；
点进注解接续查看：
@AutoConfigurationPackage ：自动配置包
@import ：Spring底层注解@import ， 给容器中导入一个组件
Registrar.class 作用：将主启动类所在包及包下面所有子包里面的所有组件扫描到Spring容器 ；
这个分析完了，退到上一步，继续看
@Import({.class}) ：给容器导入组件 ；
：自动配置导入选择器，那么它会导入哪些组件的选择器呢？我们点击去这个类看源码：
1、这个类中有一个这样的方法:
2、这个方法又调用了 SpringFactoriesLoader 类的静态方法！我们进入SpringFactoriesLoader类loadFactoryNames() 方法
3、我们继续点击查看 loadSpringFactories 方法
4、发现一个多次出现的文件：spring.factories，全局搜索它
spring.factories
我们根据源头打开spring.factories ， 看到了很多自动配置的文件；这就是自动配置根源所在！
可以看到这些一个个的都是javaConfig配置类，而且都注入了一些Bean，可以找一些自己认识的类，看着熟悉一下！
所以，自动配置真正实现是从classpath中搜寻所有的META-INF/spring.factories配置文件 ，并将其中对应的 org.springframework.boot.autoconfigure. 包下的配置项，通过反射实例化为对应标注了 @Configuration的JavaConfig形式的IOC容器配置类 ， 然后将这些都汇总成为一个实例并加载到IOC容器中。
结论：
不简单的方法
我最初以为就是运行了一个main方法，没想到却开启了一个服务；
SpringApplication.run分析
分析该方法主要分两部分，一部分是SpringApplication的实例化，二是run方法的执行
springApplication这个类主要做了以下四件事情：
1、推断应用的类型是普通的项目还是Web项目
2、查找并加载所有可用初始化器 ， 设置到initializers属性中
3、找出所有的应用程序监听器，设置到listeners属性中
4、推断并设置main方法的定义类，找到运行的主类
run方法流程分析
⑷ SpringBoot入门-自动配置详解
通过查看SpringBootApplication的源码，会发现这是一个组合注解，其中最重要的注解是@EnableAutoConfiguration
先看@AutoConfigurationPackage这个注解
里面导入了一个Registrar类，这个类实现了bean的扫描与注册，那它扫描的是哪个包呢？
只要看PackageImports这个类，会发现如果没有用@ComponentScan指定包名，他默认扫描的是启动类的包名，比如你的启动类是cn.hollycloud.App,它扫描的就是cn.hollycloud
再来看这个类，这个类用来加载所有的自动配置项
通过上面的源码我们知道spring把所有配置项都导进来了，但我们并不需要所有的功能。比如说我开发的时候并不需要mongodb相关功能，但spring也会把相关配置项加载进来，怎么关闭该功能呢？看下mongodb的自动配置源码
重点是@ConditionalOnClass(MongoClient.class),这个的意思是只有类路径中存在MongoClient.class,也就是我们导入mongo相关依赖，这个配置项才会开启，否则不会注册这个bean。
同时我们看下面有个MongoClient的bean,spring很贴心地为我们初始化好了mongo的客户端，我们直接使用就行了，如果想自定义客户端怎么办呢？也很简单，直接自己初始化一个mongo客户端放入spring容器就行了,@ConditionalOnMissingBean的意思是如果你没有自定义客户端它才会自己生成一个，是不是很方便,这个叫条件化注解
现在我们来实现一个简单的自动配置类来巩固下。
可以想象一下我们是一家机器人公司，专门制造高端机器人，很受客户欢迎，但是配置机器人过于复杂，这点老是被客户诟病，你的领导想让你提供给客户开机即用的产品，该如何实现呢？
首先我们创建一个机器人控制终端，这是控制终端可以操控机器人说话
接下来是自动配置项，可以自动注册配置终端
我们想要给客户一点自由，可以让客户自由配置机器人的名字和颜色，而不用管机器内部复杂的操作
接下来最重要的一步是把自动配置项放到类路径的/META-INF/spring.factories里面
然后客户直接引用你提供的依赖就能直接控制机器人了，而不用管复杂的初始化操作
来控制机器人说话吧，直接注入robot就能使用了，不需要客户关心复杂的初始化操作了
如果客户想为机器人改个名字也很简单，直接在application.yml配置下就行了
这个例子虽然很简单，但是说明了自动配置的工作原理，spring内置的自动配置虽然复杂，但原理都一样的。
参考代码: https://gitee.com/huatin/java-test 下的AutoConfigTest模块