springboot解剖源码

❶ boot自动配置的原理

Spring Boot是基于Spring开发的，是约定大于配置的核心思想。并且集成了大量的第三方库配置比如redis、mongoDB、jpa等。Spring Boot就相当于maven整合了所有jar包，Spring Boot整合了所有框架。其设计目的是用来简化新 Spring 应用的初始搭建以及开发过程，并不少什么新的框架。

二、Spring Boot优点

优点其实就是简单、快速

快速创建独立运行的Spring项目以及主流框架集成
使用嵌入式的server容器，应用无需打成WAR包
starters自动依赖与版本控制
有大量的自动配置，简化开发
准生产环境运行应用监控
与云计算的天然集成
Spring Boot主程序分析

//@SpringBootApplication标注这个类是一个Springboot的应用@{publicstaticvoidmain(String[] args){//将Springboot应用启动 SpringApplication.run(Springboot02DemoApplication.class, args);}}

SpringBootApplication源码剖析，进入源码，结果发现其实它是一个组合注解

第一个SpringBootConfiguration注解：@SpringBootConfiguration-->是Spring Boot配置类。下面有一个叫@Configuration：它是配置类，下面又有@Component，其实它就是一个注入组件。

第二个@EnableAutoConfiguration注解：是开启自配配置功能

@AutoConfigurationPackage//自动配置包
@Import(.class)
public @interface EnableAutoConfiguration {}

@AutoConfigurationPackage：自动配置包，使用@Import(.class)注解来完成的，它是spring boot底层注解，作用是给容器中导入组件。

自动配置原理

（1）Spring Boot启动的时候首先加载主配置类，开启啦自动配置的功能（@EnableAutoConfiguration）

（2）自动配置功能@EnableAutoConfiguration的作用：它是利用了

@Import(.class)给容器中导入一些组件。那么，他会给我们导入哪些组件呢？进入源码看一下部分源码如下。

//@EnableAutoConfiguration注解
@AutoConfigurationPackage
/@Import(.class)
public @interface EnableAutoConfiguration

@Import(.class)自动配置导入选择

public class implements DeferredImportSelector, BeanClassLoaderAware,
ResourceLoaderAware, BeanFactoryAware, EnvironmentAware, Ordered {
//----部分源码省略----//
protected AutoConfigurationEntry getAutoConfigurationEntry(AnnotationMetadata annotationMetadata) {
if (!isEnabled(annotationMetadata)) {
return EMPTY_ENTRY;
}
AnnotationAttributes attributes = getAttributes(annotationMetadata);
List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes);
//----部分源码省略----//
}

❷ 什么是Spring Boot

Spring Boot 可以轻松创建独立的、生产级的基于 Spring 的应用程序，您可以“直接运行”这些应用程序。

我们对 Spring 平台和第三方库采取了固执的观点，因此您可以轻松上手。大多数 Spring Boot 应用程序需要最少的 Spring 配置。

Spring中国教育管理中心

特征

• 创建独立的 Spring 应用程序

• 直接嵌入Tomcat、Jetty或Undertow（无需部署WAR文件）

• 提供自以为是的“入门”依赖项以简化您的构建配置

• 尽可能自动配置 Spring 和 3rd 方库

• 提供生产就绪功能，例如指标、运行状况检查和外部化配置

• 完全不需要代码生成，也不需要 XML 配置

了解更多，可查询Spring中国教育管理中心相关信息

❸ Spring Boot 自动化配置原理带图全面讲解

# Spring Boot 自动化配置原理

> 我们经常使用Spring Boot，是否知道Spring Boot自动化配置是怎么实现的呢？

<a name="iM87x"></a>

## 一 初识自动化配置

Spring Boot自动化配置依赖于@EnableAutoConfiguration注解<br />该注解会在@SpringBootApplication中包含<br />该注解为一个复合注解包含了以下注解<br />@SpringBootConfiguration 标识该类是一个配置类<br />@EnableAutoConfiguration 开启自动化配置<br />@ComponentScan 扫描该类下的所有包配置的bean<br />

<a name="TI8GH"></a>

## 二 揭开自动化配置面纱

**@EnableAutoConfiguratio**n 今天我们主要关注的是这个注解 <br />此注解为一个复合注解包含了<br />**@AutoConfigurationPackage **<br />该注解会导入一个**AutoConfigurationPackages**类<br /><br />**该方法****将主程序类所在包及所有子包下的组件到扫描到spring容器中完成****项目包下组件的自动注册**

> **至此我们完成了自动化配置中自己的组件的自动化配置，那么我们依赖的jar包自动化配置说怎么实现的呢，请继续往下看**

<br />

<a name="mz1Pw"></a>

## 三 深入自动化配置

**我们继续回到****EnableAutoConfiguration****注解 **<br />****

<a name="iHhrI"></a>

### 该注解包含2个属性：

exclude：根据类排除不使用的自动配置；<br />excludeName：根据类名排除不使用的自动配置；<br />并导入了****类 该类的核心方法为**getCandidateConfigurations**通过该方法即可获取到(spring-boot-2.1.3.RELEASE.jar/META-INF/spring.factories) 下的配置文件，该文件为spring boot自动化配置的配置文件，至此我们获取到的是所有的自动化配置类，那么spring boot的按需导入是怎么实现的呢，请继续往下看<br /><br /><br /><br /><br /><br />因为spring boot是按需配置所以我们还需要根据引入的依赖筛选出需要的配置，核心方法如下

```java

protected AutoConfigurationEntry getAutoConfigurationEntry(

AutoConfigurationMetadata autoConfigurationMetadata,

AnnotationMetadata annotationMetadata) {

        //判断是否开启自动配置

if (!isEnabled(annotationMetadata)) {

return EMPTY_ENTRY;

}

AnnotationAttributes attributes = getAttributes(annotationMetadata);

      //获取自动配置文件和配置

List<String> configurations = getCandidateConfigurations(annotationMetadata,

attributes);

        //删除重复项

configurations = removeDuplicates(configurations);

        //获取排除的自动化配置

Set<String> exclusions = getExclusions(annotationMetadata, attributes);

        //检查排除的自动化配置

checkExcludedClasses(configurations, exclusions);

      //移除排除的自动化配置

configurations.removeAll(exclusions);

      //根据引入的依赖按需导入自动配置

configurations = filter(configurations, autoConfigurationMetadata);

        //触发自动化配置

(configurations, exclusions);

return new AutoConfigurationEntry(configurations, exclusions);

}

```

filter方法会过滤我们的自动化配置类 ，规则是根据我们配置类上的  @Conditiona系列注解<br />

> @Conditiona系列注解含义，将在明天给大家讲解,明天会做一个自动配置的例子 希望大家关注一下

❹ Spring Boot 配置的优先级

本文主要参考 Externalized Configuration
为了能让应用在不同的环境下运行，Spring Boot允许自定义配置文件，如properties文件、yaml文件、系统环境变量参数、命令行参数。配置文件的覆盖优先级如下

Developer Tools 提供了一些开发帮助工具，在build.gradle添加依赖后启用。

Spring Boot会读取在计算机用户的home目录下的 .spring-boot-devtools.properties 文件里的配置参数到该计算级的所有Spring Boot应用中作为顶层配置，如Linux环境下root用户下 ~/.spring-boot-devtools.properties 文件。开发过程中，可以将一些个人参数记录在这个配置文件中，例如ip地址，机器uuid，datasource参数等。在该配置文件中的定义的配置环境并不会影响到应用配置的读取，官方原话是：

但要注意，该配置优先级最高，设置的时候需要做好记录否则会出现"原因不明的bug"，不过应该很少人会用到这个功能。分析下源码，就是加了一个配置切面，并把其设置为顶层配置：

在测试的时候，可能会使用另一套测试专用的配置，该套配置的优先级高于系统环境变量、java系统参数、程序内部参数， @TestPropertySource 注解就是用来指定这一类配置的。该注解一共有5个参数可以设置：

如果使用注解的时候没有任何参数，那么会从标注了注解的测试类的包中尝试读取配置文件，例如测试类 com.spring.test.DemoTest ，那么相应的默认配置文件为 com.spring.test.DemoTest.properties ，如果没有找到默认的配置文件则抛出非法状态异常。
在初始化上下文的时候会调用一个读取、合并配置的方法 ，该方法通过工具类 TestPropertySourceUtils 读取类的注解信息。 TestPropertySourceUtils 从类的注解解析配置信息后返回一个可合并的配置源。

@SpringBootTest 的value\properties属性用于注入一些自定义的注解，语法要求和 @TestPropertySource 的properties一样，这里就不详细展开了。

用命令行方式启动Spring Boot应用程序的时候，可以注入一些配置参数，参数的格式是 --key=name 。举个简单的例子，程序直接输出一个参数，然后打成jar包后运行。

运行：
java -jar .\springbootconfiguraiton.jar --cl.name="Spring Boot Arguments"
从输出的结果中可以看到可以读取到命令行中的配置。

可以在环境变量中定义一个key为SPRING_APPLICATION_JSON的参数，值为json字符串，Spring Boot会解析该json字符串作为参数注入到系统中。SPRING_APPLICATION_JSON可以定义在环境变量、系统配置中，命令行也是可以的，例如命令行参数中用到的demo，执行以下的命令也应该能得到相同的参数结果。
java -jar .\springbootconfiguraiton.jar SPRING_APPLICATION_JSON='{"cl":{"name"="Spring Boot Arguments"}}'
结果输出是undefined，不知道原因，这个配置方式用的应该也很少，放弃研究。。。

优先级是 ServletConfig > ServletContext ，可以在application.yml中设置：

随机数配置大多用于测试，支持的类型如下：

其中long\int可以限制数据范围，[]是闭区间，()是开区间。

这个应该是我们用的最多的。首先说优先级，文件可以放在以下4个位置，相同文件从上到下覆盖。外部指的是启动应用程序的目录，例如gradle用application插件打包后，运行的脚本目录就是 ./ ：

文件的命名为 application-[当前激活的环境名].[yml/properties] ，当前激活的配置可以用 spring.profile.active=[当前激活的环境名] 定义，多个环境名用逗号分隔，未设置时用 default 标识。关于如果修改默认的加载路径和文件名，后面会继续讨论。

Spring Boot系统启动时默认会读取的配置文件，支持properties\yml格式。也就是说，会先加载 application.properties ，根据 spring.profile.active 的设置加载相应的 application-XX.properties 配置，然后按优先级合并配置文件。
不同文件目录下application.properties的优先级和 自定义配置文件 的顺序是一样的。

类似 @TestPropertySource注解 ，在项目中可以方便的注入自定义的配置文件，注解一共有5个参数：

❺ springboot快速入门及@SpringBootApplication注解分析

简单demo
使用 maven 构建项目，官方现在稳定版本是1.5.4，第一个入门demo不是web项目，pom依赖如下：

实体 User 类：

配置类：

入口类 Application ：

项目结构目录

启动程序，以 main 方法启动：

打印出正确的结果。

来分析一下流程，为何 Runnable 类， User ， Map 会纳入spring容器。

首先我们分析的就是入口类 Application 的启动注解 @SpringBootApplication ，进入源码：

发现 @SpringBootApplication 是一个复合注解，包括 @ComponentScan ，和 @SpringBootConfiguration ， @EnableAutoConfiguration 。

根据上面的理解，上面的入口类 Application ，我们可以使用：

使用 @ComponentScan 注解代替 @SpringBootApplication 注解，也可以正常运行程序。原因是 @SpringBootApplication 中包含 @ComponentScan ，并且 springboot 会将入口类看作是一个 @SpringBootConfiguration 标记的配置类，所以定义在入口类 Application 中的 Runnable 也可以纳入到容器管理。

看一个demo学会使用这些参数配置
在包下com.hao.miao.springboot定义一个启动应用类（加上@SpringBootApplication注解）

在com.hao.miao.beans包下定义一个实体类，并且想将其纳入到spring容器中，

启动启动类，打印结果如下：

说明Cat类并没有纳入到spring容器中，这个结果也如我们所想，因为@SpringBootApplication只会扫描@SpringBootApplication注解标记类包下及其子包的类（特定注解标记，比如说@Controller，@Service，@Component,@Configuration和@Bean注解等等）纳入到spring容器，很显然MyConfig不在@SpringBootApplication注解标记类相同包下及其子包的类，所以需要我们去配置一下扫包路径。

修改启动类，@SpringBootApplication(scanBasePackages = "com.hao.miao")，指定扫描路径：

启动并打印：

当然使用@SpringBootApplication(scanBasePackageClasses = MyConfig.class)，指定scanBasePackageClasses参数的value值是你需要扫描的类也可以，结果一样，不过如果多个配置类不在当前包及其子包下，则需要指定多个。

再看一个列子，
在上面的列子的相同包下（com.hao.miao.springboot）配置了People，并将其纳入到spring容器中（@Component），我们知道@SpringBootApplication注解会扫描当前包及其子包，所以People类会纳入到spring容器中去，我们需要将其排除在spring容器中，如何操作？
可以使用@SpringBootApplication的另外二个参数（exclude或excludeName）

启动类，

启动并打印结果：

然后修改@SpringBootApplication配置，

很明显启动报错。使用@excludeName注解也可以。如下，
@SpringBootApplication(excludeName = {"com.hao.miao.springboot.People"})

参考文档：
Springboot1.5.4官方文档

❻ Spring Boot 最核心的 25 个注解，都是干货！

Spring Boot 最核心的 25 个注解
1、@SpringBootApplication

这是 Spring Boot 最最最核心的注解，用在 Spring Boot 主类上，标识这是一个 Spring Boot 应用，用来开启 Spring Boot 的各项能力。

其实这个注解就是 @SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan 这三个注解的组合，也可以用这三个注解来代替 @SpringBootApplication 注解。

2、@EnableAutoConfiguration

允许 Spring Boot 自动配置注解，开启这个注解之后，Spring Boot 就能根据当前类路径下的包或者类来配置 Spring Bean。

如：当前类路径下有 Mybatis 这个 JAR 包，MybatisAutoConfiguration 注解就能根据相关参数来配置 Mybatis 的各个 Spring Bean。

3、@Configuration

这是 Spring 3.0 添加的一个注解，用来代替 applicationContext.xml 配置文件，所有这个配置文件里面能做到的事情都可以通过这个注解所在类来进行注册。

4、@SpringBootConfiguration

这个注解就是 @Configuration 注解的变体，只是用来修饰是 Spring Boot 配置而已，或者可利于 Spring Boot 后续的扩展。

5、@ComponentScan

这是 Spring 3.1 添加的一个注解，用来代替配置文件中的 component-scan 配置，开启组件扫描，即自动扫描包路径下的 @Component 注解进行注册 bean 实例到 context 中。

前面 5 个注解可以在这篇文章《Spring Boot 最核心的 3 个注解详解》中了解更多细节的。

6、@Conditional

这是 Spring 4.0 添加的新注解，用来标识一个 Spring Bean 或者 Configuration 配置文件，当满足指定的条件才开启配置。

7、@ConditionalOnBean

组合 @Conditional 注解，当容器中有指定的 Bean 才开启配置。

8、@ConditionalOnMissingBean

组合 @Conditional 注解，和 @ConditionalOnBean 注解相反，当容器中没有指定的 Bean 才开启配置。

9、@ConditionalOnClass

组合 @Conditional 注解，当容器中有指定的 Class 才开启配置。

10、@ConditionalOnMissingClass

组合 @Conditional 注解，和 @ConditionalOnMissingClass 注解相反，当容器中没有指定的 Class 才开启配置。

11、@ConditionalOnWebApplication

组合 @Conditional 注解，当前项目类型是 WEB 项目才开启配置。

当前项目有以下 3 种类型。

enum Type {

}

12、@

组合 @Conditional 注解，和 @ConditionalOnWebApplication 注解相反，当前项目类型不是 WEB 项目才开启配置。

13、@ConditionalOnProperty

组合 @Conditional 注解，当指定的属性有指定的值时才开启配置。

14、@ConditionalOnExpression

组合 @Conditional 注解，当 SpEL 表达式为 true 时才开启配置。

15、@ConditionalOnJava

组合 @Conditional 注解，当运行的 Java JVM 在指定的版本范围时才开启配置。

16、@ConditionalOnResource

组合 @Conditional 注解，当类路径下有指定的资源才开启配置。

17、@ConditionalOnJndi

组合 @Conditional 注解，当指定的 JNDI 存在时才开启配置。

18、@ConditionalOnCloudPlatform

组合 @Conditional 注解，当指定的云平台激活时才开启配置。

19、@ConditionalOnSingleCandidate

组合 @Conditional 注解，当指定的 class 在容器中只有一个 Bean，或者同时有多个但为首选时才开启配置。

20、@ConfigurationProperties

用来加载额外的配置（如 .properties 文件），可用在 @Configuration 注解类，或者 @Bean 注解方法上面。

21、@EnableConfigurationProperties

一般要配合 @ConfigurationProperties 注解使用，用来开启对 @ConfigurationProperties 注解配置 Bean 的支持。

22、@AutoConfigureAfter

用在自动配置类上面，表示该自动配置类需要在另外指定的自动配置类配置完之后。

如 Mybatis 的自动配置类，需要在数据源自动配置类之后。

23、@AutoConfigureBefore

这个和 @AutoConfigureAfter 注解使用相反，表示该自动配置类需要在另外指定的自动配置类配置之前。

24、@Import

这是 Spring 3.0 添加的新注解，用来导入一个或者多个 @Configuration 注解修饰的类，这在 Spring Boot 里面应用很多。

25、@ImportResource

这是 Spring 3.0 添加的新注解，用来导入一个或者多个 Spring 配置文件，这对 Spring Boot 兼容老项目非常有用，因为有些配置无法通过 Java Config 的形式来配置就只能用这个注解来导入。

欢迎Java工程师朋友们加入Java高并发： 957734884 ，群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！

❼ 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原理

前端常使用模板引擎，主要有FreeMarker和Thymeleaf，它们都是用Java语言编写的，渲染模板并输出相应文本，使得界面的设计与应用的逻辑分离，同时前端开发还会使用到Bootstrap、AngularJS、JQuery等；

在浏览器的数据传输格式上采用Json，非xml，同时提供RESTfulAPI；SpringMVC框架用于数据到达服务器后处理请求；到数据访问层主要有Hibernate、MyBatis、JPA等持久层框架；数据库常用MySQL；开发工具推荐IntelliJIDEA。

(8)springboot解剖源码扩展阅读：

SpringBoot所具备的特征有：

（1）可以创建独立的Spring应用程序，并且基于其Maven或Gradle插件，可以创建可执行的JARs和WARs；

（2）内嵌Tomcat或Jetty等Servlet容器；

（3）提供自动配置的“starter”项目对象模型（POMS）以简化Maven配置；

（4）尽可能自动配置Spring容器；

（5）提供准备好的特性，如指标、健康检查和外部化配置；

（6）绝对没有代码生成，不需要XML配置。

Spring的初衷：

1、JAVA EE开发应该更加简单。

2、使用接口而不是使用类，是更好的编程习惯。Spring将使用接口的复杂度几乎降低到了零。

3、为JavaBean提供了一个更好的应用配置框架。

4、更多地强调面向对象的设计，而不是现行的技术如JAVA EE。

5、尽量减少不必要的异常捕捉。

6、使应用程序更加容易测试。

❾ [Spring boot源码解析] 2 启动流程分析

在了解 Spring Boot 的启动流程的时候，我们先看一下一个Spring Boot 应用是如何启动的，如下是一个简单的 SpringBoot 程序，非常的简洁，他是如何做到的呢，我们接下来就将一步步分解。

我们追踪 SpringApplication.run() 方法，其实最终它主要的逻辑是新建一个 SpringApplication ，然后调用他的 run 方法，如下:

我们先来看一下创建 SpringApplication 的方法：

在将Main class 设置 primarySources 后，调用了 WebApplicationType.deceFromClasspath() 方法，该方法是为了检查当前的应用类型，并设置给 webApplicationType 。 我们进入 deceFromClasspath 方法 ：

这里主要是通过类加载器判断是否存在 REACTIVE 相关的类信息，假如有就代表是一个 REACTIVE 的应用，假如不是就检查是否存在 Servelt 和 ，假如都没有，就代表应用为非 WEB 类应用，返回 NONE ，默认返回 SERVLET 类型，我们这期以我们目前最常使用的 SERVLET 类型进行讲解，所以我们在应用中引入了 spring-boot-starter-web 作为依赖：

他会包含 Spring-mvc 的依赖，所以就包含了内嵌 tomcat 中的 Servlet 和 Spring-web 中的 ,因此返回了 SERVLET 类型。

回到刚才创建 SpringApplication 的构建方法中，我们设置完成应用类型后，就寻找所有的 Initializer 实现类，并设置到 SpringApplication 的 Initializers 中，这里先说一下 getSpringFactoriesInstances 方法，我们知道在我们使用 SpringBoot 程序中，会经常在 META-INF/spring.factories 目录下看到一些 EnableAutoConfiguration ，来出发 config 类注入到容器中，我们知道一般一个 config 类要想被 SpringBoot 扫描到需要使用 @CompnentScan 来扫描具体的路径，对于 jar 包来说这无疑是非常不方便的，所以 SpringBoot 提供了另外一种方式来实现，就是使用 spring.factories ，比如下面这个，我们从 Springboot-test 中找到的例子，这里先定义了一个ExampleAutoConfiguration，并加上了 Configuration 注解：

然后在 spring.factories 中定义如下：

那这种方式是怎么实现的你，这就要回到我们刚才的方法 getSpringFactoriesInstances :

我们先来看一下传入参数，这里需要注意的是 args，这个是初始化对应 type 的时候传入的构造参数，我们先看一下 SpringFactoriesLoader#loadFactoryNames 方法：

首先是会先检查缓存，假如缓存中存在就直接返回，假如没有就调用 classLoader#getResources 方法，传入 META-INF/spring.factories ，即获取所有 jar 包下的对应文件，并封装成 UrlResource ，然后使用 PropertiesLoaderUtils 将这些信息读取成一个对一对的 properties，我们观察一下 spring.factories 都是按 properties 格式排版的，假如有多个就用逗号隔开，所以这里还需要将逗号的多个类分隔开来，并加到 result 中，由于 result 是一个 LinkedMultiValueMap 类型，支持多个值插入，最后放回缓存中。最终完成加载 META-INF/spring.factories 中的配置，如下：

我们可以看一下我们找到的 initializer 有多少个：

在获取到所有的 Initializer 后接下来是调用 方法进行初始化。

这里的 names 就是我们上面通过类加载器加载到的类名，到这里会先通过反射生成 class 对象，然后判断该类是否继承与 ApplicationContextInitializer ，最后通过发射的方式获取这个类的构造方法，并调用该构造方法，传入已经定义好的构造参数，对于 ApplicationContextInitializer 是无参的构造方法，然后初始化实例并返回，回到原来的方法，这里会先对所有的 ApplicationContextInitializer 进行排序，调用 #sort(instances) 方法，这里就是根据 @Order 中的顺序进行排序。

接下来是设置 ApplicationListener ，我们跟进去就会发现这里和上面获取 ApplicationContextInitializer 的方法如出一辙，最终会加载到如图的 15 个 listener （这里除了 外，其他都是 SpringBoot 内部的 Listener）:

在完成 SpringApplication 对象的初始化后，我们进入了他的 run 方法，这个方法几乎涵盖了 SpringBoot 生命周期的所有内容，主要分为九个步骤，每一个步骤这里都使用注解进行标识：

主要步骤如下：
第一步：获取 SpringApplicationRunListener， 然后调用他的 staring 方法启动监听器。
第二步：根据 SpringApplicationRunListeners以及参数来准备环境。
第三步：创建 Spring 容器。
第四步：Spring 容器的前置处理。
第五步：刷新 Spring 容器。
第六步： Spring 容器的后置处理器。
第七步：通知所有 listener 结束启动。
第八步：调用所有 runner 的 run 方法。
第九步：通知所有 listener running 事件。
我们接下来一一讲解这些内容。

我们首先看一下第一步，获取 SpringApplicationRunListener :

这里和上面获取 initializer 和 listener 的方式基本一致，都是通过 getSpringFactoriesInstances , 最终只找到一个类就是： org.springframework.boot.context.event.EventPublishingRunListener ，然后调用其构造方法并传入产生 args , 和 SpringApplication 本身:

我们先看一下构造函数，首先将我们获取到的 ApplicationListener 集合添加到initialMulticaster 中， 最后都是通过操作 来进行广播，我，他继承于 ，我们先看一下他的 addApplicationListener 方法：

我们可以看出，最后是放到了 applicationListenters 这个容器中。他是 defaultRetriever 的成员属性， defaultRetriever 则是 的私有类，我们简单看一下这个类：

我们只需要看一下这里的 getApplicationListeners 方法，它主要是到 beanFactory 中检查是否存在多的 ApplicationListener 和旧的 applicationListeners 组合并返回，接着执行 listener 的 start 方法，最后也是调用了 的 multicastEvent 查找支持对应的 ApplicationEvent 类型的通知的 ApplicationListener 的 onApplicationEvent 方法 ,这里除了会:

筛选的方法如下，都是调用了对应类型的 supportsEventType 方法 ：

如图，我们可以看到对 org.springframework.boot.context.event.ApplicationStartingEvent 感兴趣的有5个 Listener

环境准备的具体方法如下：

首先是调用 getOrCreateEnvironment 方法来创建 environment ，我们跟进去可以发现这里是根据我们上面设置的环境的类型来进行选择的，当前环境会创建 StandardServletEnvironment

我们先来看一下 StandardServletEnvironment 的类继承关系图，我们可以看出他是继承了 AbstractEnvironment ：

他会调用子类的 customizePropertySources 方法实现,首先是 StandardServletEnvironment 的实现如下，他会添加 servletConfigInitParams , servletContextInitParams , jndiProperties 三种 properties，当前调试环境没有配置 jndi properties，所以这里不会添加。接着调用父类的 customizePropertySources 方法，即调用到了 StandardEnvironment 。

我们看一下 StandardEnvironment#customizePropertySources 方法，与上面的三个 properties 创建不同，这两个是会进行赋值的，包括系统环境变量放入 systemEnvironment 中，jvm 先关参数放到 systemProperties 中：

这里会添加 systemEnvironment 和 systemProperties 这两个 properties，最终拿到的 properties 数量如下 4个：

在创建完成 Environment 后，接下来就到了调用 configureEnvironment 方法：

我们先看一下 configurePropertySources 方法，这里主要分两部分，首先是查询当前是否存在 defaultProperties ，假如不为空就会添加到 environment 的 propertySources 中，接着是处理命令行参数，将命令行参数作为一个 CompositePropertySource 或则 添加到 environment 的 propertySources 里面，

接着调用 ConfigurationPropertySources#attach 方法,他会先去 environment 中查找 configurationProperties , 假如寻找到了，先检查 configurationProperties 和当前 environment 是否匹配，假如不相等，就先去除，最后添加 configurationProperties 并将其 sources 属性设置进去。

回到我们的 prepareEnvironment 逻辑，下一步是通知观察者，发送 事件，调用的是 SpringApplicationRunListeners#environmentPrepared 方法，最终回到了 #multicastEvent 方法，我们通过 debug 找到最后对这个时间感兴趣的 Listener 如下：

其主要逻辑如下：

这个方法最后加载了 PropertySourceLoader , 这里主要是两种，一个是用于 Properties 的，一个是用于 YAML 的如下：

其中 apply 方法主要是加载 defaultProperties ，假如已经存在，就进行替换，而替换的目标 PropertySource 就是 load 这里最后的一个 consumer 函数加载出来的，这里列一下主要做的事情：
1、加载系统中设置的所有的 Profile 。
2、遍历所有的 Profile ，假如是默认的 Profile ， 就将这个 Profile 加到 environment 中。
3、调用load 方法，加载配置，我们深入看一下这个方法：

他会先调用 getSearchLocations 方法，加载所有的需要加载的路径，最终有如下路径：

其核心方法是遍历所有的 propertySourceLoader ，也就是上面加载到两种 propertySourceLoader ,最红 loadForFileExtension 方法，加载配置文件，这里就不展开分析了，说一下主要的作用，因为每个 propertySourceLoader 都有自己可以加载的扩展名，默认扩展名有如下四个 properties, xml, yml, yaml，所以最终拿到文件名字，然后通过 - 拼接所有的真实的名字，然后加上路径一起加载。

接下来，我们分析 BackgroundPreinitializer ,这个方法在接收 ApplicationPrepareEnvironment 事件的时候真正调用了这份方法：

1、 ConversionServiceInitializer 主要负责将包括 日期，货币等一些默认的转换器注册到 formatterRegistry 中。
2、 ValidationInitializer 创建 validation 的匹配器。
3、 MessageConverterInitializer 主要是添加了一些 http 的 Message Converter。
4、 JacksonInitializer 主要用于生成 xml 转换器的。
接着回到我们将的主体方法， prepareEnvironment 在调用完成 listeners.environmentPrepared(environment) 方法后，调用 bindToSpringApplication(environment) 方法，将 environment 绑定到 SpirngApplication 中。
接着将 enviroment 转化为 StandardEnvironment 对象。
最后将 configurationProperties 加入到 enviroment 中， configurationProperties 其实是将 environment 中其他的 PropertySource 重新包装了一遍，并放到 environment 中，这里主要的作用是方便 进行解析。

它主要是检查是否存在 spring.beaninfo.ignore 配置，这个配置的主要作用是设置 javaBean 的内省模式，所谓内省就是应用程序在 Runtime 的时候能检查对象类型的能力，通常也可以称作运行时类型检查，区别于反射主要用于修改类属性，内省主要用户获取类属性。那么我们什么时候会使用到内省呢，java主要是通过内省工具 Introspector 来完成内省的工作，内省的结果通过一个 Beaninfo 对象返回，主要包括类的一些相关信息，而在 Spring中，主要是 BeanUtils#Properties 会使用到，Spring 对内省机制还进行了改进，有三种内省模式，如下图中红色框框的内容，默认情况下是使用 USE_ALL_BEANINFO。假如设置为true，就是改成第三中 IGNORE_ALL_BEANINFO

首先是检查 Application的类型，然后获取对应的 ApplicationContext 类，我们这里是获取到了 org.springframework.boot.web.servlet.context. 接着调用 BeanUtils.instantiateClass(contextClass); 方法进行对象的初始化。

最终其实是调用了 的默认构造方法。我们看一下这个方法做了什么事情。这里只是简单的设置了一个 reader 和一个 scanner，作用于 bean 的扫描工作。

我们再来看一下这个类的继承关系

这里获取 ExceptionReporter 的方式主要还是和之前 Listener 的方式一致,通过 getSpringFactoriesInstances 来获取所有的 SpringBootExceptionReporter 。

其主要方法执行如下：

❿ SpringBoot自动配置的原理及实现/SpringBoot之@Import注解正确使用方式

https://www.jianshu.com/p/6b2f672e2446
了解SpringBoot之@Import注解正确使用方式

SpringBoot 的核心就是自动配置，自动配置又是基于条件判断来配置 Bean。关于自动配置的源码在 spring-boot -autoconfigure-2.0.3.RELEASE.jar

在通常需要我们在 property 中配置信息时，通常使用 @ConfigurationProperties(pefix=“前缀”) 注解的方式从配置文件中获取配置，如下：

application.yml 中配置信息

访问 url 获取配置信息返回的值
http://localhost:8080/msg

如果把 application.yml 中的配置信息注释掉则默认使用 default 值，否则使用配置信息中的值，以上便是普通配置方式

SpringBoot 运行原理
先看 @SpringBootApplication

主要关注的几个注解如下
@SpringBootConfiguration：标记当前类为配置类
@EnableAutoConfiguration：开启自动配置
@ComponentScan：扫描主类所在的同级包以及下级包里的 Bean
关键是 @EnableAutoConfiguration

最关键的要属 @Import(.class)，借助** **，@EnableAutoConfiguration 可以帮助 SpringBoot 应用将所有符合条件的 @Configuration 配置都加载到当前 SpringBoot 创建并使用的 IoC 容器: 通过 @Import(.class) 导入的配置功能，
中的方法 getCandidateConfigurations，得到待配置的 class 的类名集合, 这个集合就是所有需要进行自动配置的类，而是是否配置的关键在于 META-INF/spring.factories 文件中是否存在该配置信息

打开，如下图可以看到所有需要配置的类全路径都在文件中，每行一个配置，多个类名逗号分隔, 而 \ 表示忽略换行

整个流程如上图所示

以 类来看其主要构成部分

都能看到各种各样的条件判断注解，满足条件时就加载这个 Bean 并实例化
此类的条件注解是：@ConditionalOnProperty

@ConditionalOnBean：当容器里有指定 Bean 的条件下
@ConditionalOnClass：当类路径下有指定的类的条件下
@ConditionalOnExpression：基于 SpEL 表达式为 true 的时候作为判断条件才去实例化
@ConditionalOnJava：基于 JVM 版本作为判断条件
@ConditionalOnJndi：在 JNDI 存在的条件下查找指定的位置
@ConditionalOnMissingBean：当容器里没有指定 Bean 的情况下
@ConditionalOnMissingClass：当容器里没有指定类的情况下
@ConditionalOnWebApplication：当前项目时 Web 项目的条件下
@：当前项目不是 Web 项目的条件下
@ConditionalOnProperty：指定的属性是否有指定的值
@ConditionalOnResource：类路径是否有指定的值
@：当指定 Bean 在容器中只有一个，或者有多个但是指定首选的 Bean
这些注解都组合了 @Conditional 注解，只是使用了不同的条件组合最后为 true 时才会去实例化需要实例化的类，否则忽略
这种 spring4.X 带来的动态组合很容易后期配置，从而避免了硬编码，使配置信息更加灵活多变，同时也避免了不必要的意外异常报错。使用的人只要知道配置的条件即可也不用去阅读源码，方便快捷，这也是 sprignboot 快捷方式带来的好处

参考 HttpEncodingAutoConfiguration 配置信息如下

案例扩展

项目

需要实例化的服务类

配置信息对应的属性映射类, 需要 pom 中加入 spring-boot-starter 依赖

自动配置文件

在创建如下路径文件 src/main/resources/META-INF/spring.factories

必须是自动配置类的全路径

mvn install 该项目

创建一个 springboot-mvc 项目 pom 依赖上面的 jar

http://localhost:8080 / 则返回当前服务的默认值

在 applicaton.yml 中加, 重启刷新则会更新为如下信息

SpringBoot 自动化配置关键组件关系图
mybatis-spring-boot-starter、spring-boot-starter-web 等组件的 META-INF 文件下均含有 spring.factories 文件，自动配置模块中，SpringFactoriesLoader 收集到文件中的类全名并返回一个类全名的数组，返回的类全名通过反射被实例化，就形成了具体的工厂实例，工厂实例来生成组件具体需要的 bean。

在 spring boot 中有时候需要控制配置类是否生效, 可以使用 @ConditionalOnProperty 注解来控制 @Configuration 是否生效.