springboot源码解析（springboot源码编译）

今天给各位分享springboot源码解析的知识，其中也会对springboot源码编译进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、[Spring boot源码解析] 2 启动流程分析
• 2、SpringBoot内置生命周期事件详解 SpringBoot源码(十)
• 3、Springboot下的RabbitMQ消息监听源码解读
• 4、Springboot初始化流程解析
• 5、Springboot自定义xml文件解析
• 6、springboot快速入门及@SpringBootApplication注解分析

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

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

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

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

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

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

他会包含 Spring-mvc 的依赖，所以就包含了内嵌 tomcat 中的 Servlet 和 Spring-web 中的 ConfigurableWebApplicationContext ,因此返回了 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 后接下来是调用 createSpringFactoriesInstances 方法进行初始化。

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

接下来是设置 ApplicationListener ，我们跟进去就会发现这里和上面获取 ApplicationContextInitializer 的方法如出一辙，最终会加载到如图的 15 个 listener （这里除了 EnableEncryptablePropertiesBeanFactoryPostProcessor 外，其他都是 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 中， 最后都是通过操作 SimpleApplicationEventMulticaster 来进行广播，我，他继承于 AbstractApplicationEventMulticaster ，我们先看一下他的 addApplicationListener 方法：

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

我们只需要看一下这里的 getApplicationListeners 方法，它主要是到 beanFactory 中检查是否存在多的 ApplicationListener 和旧的 applicationListeners 组合并返回，接着执行 listener 的 start 方法，最后也是调用了 AbstractApplicationEventMulticaster 的 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 或则 SimpleCommandLinePropertySource 添加到 environment 的 propertySources 里面，

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

回到我们的 prepareEnvironment 逻辑，下一步是通知观察者，发送 ApplicationEnvironmentPreparedEvent 事件，调用的是 SpringApplicationRunListeners#environmentPrepared 方法，最终回到了 SimpleApplicationEventMulticaster#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 中，这里主要的作用是方便 PropertySourcesPropertyResolver 进行解析。

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

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

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

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

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

其主要方法执行如下：

SpringBoot内置生命周期事件详解 SpringBoot源码(十)

SpringBoot中文注释项目Github地址：

本篇接 SpringBoot事件监听机制源码分析(上) SpringBoot源码(九)

温故而知新，我们来简单回顾一下上篇的内容，上一篇我们分析了 SpringBoot启动时广播生命周期事件的原理 ，现将关键步骤再浓缩总结下：

上篇文章的侧重点是分析了SpringBoot启动时广播生命周期事件的原理，此篇文章我们再来详细分析SpringBoot内置的7种生命周期事件的源码。

分析SpringBoot的生命周期事件，我们先来看一张类结构图：

由上图可以看到事件类之间的关系：

EventObject 类是JDK的事件基类，可以说是所有Java事件类的基本，即所有的Java事件类都直接或间接继承于该类，源码如下：

可以看到 EventObject 类只有一个属性 source ，这个属性是用来记录最初事件是发生在哪个类，举个栗子，比如在SpringBoot启动过程中会发射 ApplicationStartingEvent 事件，而这个事件最初是在 SpringApplication 类中发射的，因此 source 就是 SpringApplication 对象。

ApplicationEvent 继承了DK的事件基类 EventObject 类，是Spring的事件基类，被所有Spring的具体事件类继承，源码如下：

可以看到 ApplicationEvent 有且仅有一个属性 timestamp ，该属性是用来记录事件发生的时间。

SpringApplicationEvent 类继承了Spring的事件基类 ApplicationEvent ，是所有SpringBoot内置生命周期事件的父类，源码如下：

可以看到 SpringApplicationEvent 有且仅有一个属性 args ，该属性就是SpringBoot启动时的命令行参数即标注 @SpringBootApplication 启动类中 main 函数的参数。

接下来我们再来看一下 SpringBoot 内置生命周期事件即 SpringApplicationEvent 的具体子类们。

SpringBoot开始启动时便会发布 ApplicationStartingEvent 事件，其发布时机在环境变量Environment或容器ApplicationContext创建前但在注册 ApplicationListener 具体监听器之后，标志标志 SpringApplication 开始启动。

可以看到 ApplicationEnvironmentPreparedEvent 事件多了一个 environment 属性，我们不妨想一下，多了 environment 属性的作用是啥？

答案就是 ApplicationEnvironmentPreparedEvent 事件的 environment 属性作用是利用事件发布订阅机制，相应监听器们可以从 ApplicationEnvironmentPreparedEvent 事件中取出 environment 变量，然后我们可以为 environment 属性增加属性值或读出 environment 变量中的值。

当SpringApplication已经开始启动且环境变量 Environment 已经创建后，并且为环境变量 Environment 配置了命令行和 Servlet 等类型的环境变量后，此时会发布 ApplicationEnvironmentPreparedEvent 事件。

监听 ApplicationEnvironmentPreparedEvent 事件的第一个监听器是 ConfigFileApplicationListener ，因为是 ConfigFileApplicationListener 监听器还要为环境变量 Environment 增加 application.properties 配置文件中的环境变量；此后还有一些也是监听 ApplicationEnvironmentPreparedEvent 事件的其他监听器监听到此事件时，此时可以说环境变量 Environment 几乎已经完全准备好了。

可以看到 ApplicationContextInitializedEvent 事件多了个 ConfigurableApplicationContext 类型的 context 属性， context 属性的作用同样是为了相应监听器可以拿到这个 context 属性执行一些逻辑，具体作用将在 3.4.4 详述。

ApplicationContextInitializedEvent 事件在 ApplicationContext 容器创建后，且为 ApplicationContext 容器设置了 environment 变量和执行了 ApplicationContextInitializers 的初始化方法后但在bean定义加载前触发，标志ApplicationContext已经初始化完毕。

同样可以看到 ApplicationPreparedEvent 事件多了个 ConfigurableApplicationContext 类型的 context 属性，多了 context 属性的作用是能让监听该事件的监听器们能拿到 context 属性，监听器拿到 context 属性一般有如下作用：

ApplicationPreparedEvent 事件在 ApplicationContext 容器已经完全准备好时但在容器刷新前触发，在这个阶段 bean 定义已经加载完毕还有 environment 已经准备好可以用了。

ApplicationStartedEvent 事件将在容器刷新后但 ApplicationRunner 和 CommandLineRunner 的 run 方法执行前触发，标志 Spring 容器已经刷新，此时容器已经准备完毕了。

ApplicationReadyEvent 事件在调用完 ApplicationRunner 和 CommandLineRunner 的 run 方法后触发，此时标志 SpringApplication 已经正在运行。

可以看到 ApplicationFailedEvent 事件除了多了一个 context 属性外，还多了一个 Throwable 类型的 exception 属性用来记录SpringBoot启动失败时的异常。

ApplicationFailedEvent 事件在SpringBoot启动失败时触发，标志SpringBoot启动失败。

此篇文章相对简单，对SpringBoot内置的7种生命周期事件进行了详细分析。我们还是引用上篇文章的一张图来回顾一下这些生命周期事件及其用途：

由于有一些小伙伴们建议之前有些源码分析文章太长，导致耐心不够，看不下去，因此，之后的源码分析文章如果太长的话，笔者将会考虑拆分为几篇文章，这样就比较短小了，比较容易看完，嘿嘿。

【源码笔记】Github地址：

点赞搞起来，嘿嘿嘿！

公众号【 源码笔记 】专注于Java后端系列框架的源码分析。

Springboot下的RabbitMQ消息监听源码解读

以上配置比较简单，都是一些基本的配置，配置Rabbit的连接工厂，配置Template，客户端操作的模版RabbitTemplate对象。

注解核心配置

主要注册一个BeanPostProcessor和RabbitListenerEndpointRegistry创建消息监听容器管理生命周期。

RabbitBootstrapConfiguration.java

在上一步将所有的方法（方法上有@RabbitListener注解的）解析处理后，接下来开始处理消息监听

接着上面构建完MethodRabbitListenerEndpoint对象后，将所有的监听方法保存

到此消息监听@RabbitListener注解的方法就处理完成了，所有的监听方法都保存到了RabbitListenerAnnotationBeanPostProcessor.registrar.endpointDescriptors集合中。

RabbitListenerAnnotationBeanPostProcessor 处理器程序实现了SmartInitializingSingleton接口，所以在所有的Bean创建完成以后会执行Bean实现了SmartInitializingSingleton#afterSingletonsInstantiated的方法。

注册监听程序

注册监听容器

监听容器工厂父类创建监听容器

到此消息监听容器MessageListenerContainer（SimpleMessageListenerContainer）对象创建完成，

到这里主要的消息监听容器都创建完成后接下来就是启动消息监听容器了。

在2.2中注册了RabbitListenerEndpointRegistry 对象，该类实现了SmartLifecycle接口，也实现了ApplicationListener接口，并且处理的是ContextRefreshedEvent事件。

上面这两个动作都会在容器上下文初始化完成以后触发，在AbstractApplicationContext#refresh#finishRefresh方法中触发

开始消息监听

异步消息处理消费者AsyncMessageProcessingConsumer

事件处理

RabbitAutoConfiguration ===》RabbitAnnotationDrivenConfiguration ===》EnableRabbitConfiguration ===》 @EnableRabbit

注册RabbitListenerAnnotationBeanPostProcessor处理器处理@RabbitListener和@RabbitHandler注解

RabbitListenerAnnotationBeanPostProcessor类

将上一步解析出来的所有方法及对应的@RabbitListener注解中配置的信息进行包装到MethodRabbitListenerEndpoint中

说明：@RabbitListener注解中的errorHandler属性可以是SpEL表达式也可以是一个Bean的名称

该步骤中主要就是设置相关的一些属性信息到Endpoint中，比如：ackMode，queueName，concurrency等信息。

构造完Endpoint对象后将其保存到RabbitListenerEndpointRegistrar中。

RabbitListenerAnnotationBeanPostProcessor类实现了SmartInitializingSingleton接口，当所有的Bean初始化完成以后会执行实现了SmartInitializingSingleton接口Bean的回调方法afterSingletonsInstantiated。

在afterSingletonsInstantiated方法中调用RabbitListenerAnnotationBeanPostProcessor.registrar(RabbitListenerEndpointRegistrar)#afterPropertiesSet

方法。

在afterPropertiesSet方法中就是注册Endpoint了，在该方法中将所有的Endpoint再封装成MessageListenerContainer(SimpleMessageListenerContainer)

对象，最后将MessageListenerContainer对象保存到RabbitListenerEndpointRegistry.listenerContainers的Map集合中。

在这里是还没有启动所有的监听程序。

RabbitListenerEndpointRegistry对象Bean实现了SmartLifecycle接口，所以容器上下文执行完（刷新完）以后会调用实现了该接口的会滴方法start，启动消息监听。

SpringBoot多数据源配置详解

SpringBoot邮件发送示例

Springboot面试题整理附答案

SpringBoot配置文件你了解多少？

SpringBoot项目查看线上日志

springboot mybatis jpa 实现读写分离

Springboot整合openfeign使用详解

SpringBoot RabbitMQ消息可靠发送与接收

Springboot整合MyBatis复杂查询应用

Springboot整合RabbitMQ死信队列详解

Springboot初始化流程解析

以上是一个最简单的Springboot程序（2.0.3版本）示例，也是我们最通用的写法，但其中其实封装这一系列复杂的功能操作，让我们开始逐步进行分析。

首先这里最重要的必然是注解 @SpringBootApplication

@SpringBootApplication 注解由几个注解复合组成，其中最主要的就是 @SpringBootConfiguration 、 @EnableAutoConfiguration 和 @ComponentScan 这三个。

其中的 @ComponentScan 是spring的原生注解， @SpringBootConfiguration 虽然是springboot中的注解，但其实质就是包装后的 @Configuration ，仍然是spring中的注解，用于代替xml的方式管理配置bean

@EnableAutoConfiguration 的定义如上，这里最重要的注解是 @Import （ @AutoConfigurationPackage 注解的实现也是基于 @Import ），借助 @Import 的帮助，将所有符合自动配置条件的bean定义加载到IoC容器中。关于 @EnableAutoConfiguration 注解后续涉及到时会再详细说明。这里我们先回到启动类的 run 方法从头分析初始化流程。

可以看到'run'方法最终调用的是 new SpringApplication(primarySources).run(args) ，这里首先创建了 SpringApplication 对象，然后调用其 run 方法

这里主要是为 SpringApplication 对象进行初始化，这里要专门提一下的是 webApplicationType 和 getSpringFactoriesInstances 。

它用来标识我们的应用是什么类型的应用，来看一下 deduceWebApplicationType() 方法的实现

其返回值是 WebApplicationType 类型的枚举类，其值有 NONE 、 SERVLET 、 REACTIVE 三种，分别对应非WEB应用，基于servlet的WEB应用和基于reactive的WEB应用。

这里的核心是 SpringFactoriesLoader.loadFactoryNames(type, classLoader) 方法，来看一下

重点关注一下 loadSpringFactories(classLoader) 做了什么

这里的 FACTORIES_RESOURCE_LOCATION 定义为 META-INF/spring.factories ，因此该方法会扫描所有包下的该文件，将其解析成map对象并缓存到 cache 中以避免重复加载，springboot包下该文件的部分片段如下

从这里可以看出， setInitializers((Collection) getSpringFactoriesInstances( ApplicationContextInitializer.class)) 和 setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class)); 分别对应设置的是上述这些类。

解析完成后调用 createSpringFactoriesInstances(type, parameterTypes, classLoader, args, names) 处理解析结果，生成对应的实例，源码如下

这里的核心是通过 ClassUtils.forName(name, classLoader) 方法，以反射的方式生成类实例 instanceClass 。由此可以看出 SpringFactoriesLoader.loadFactoryNames(type, classLoader) 的作用就是将 META-INF/spring.factories 中配置的内容进行实例化的工厂方法类，具备很强的扩展性，与SPI机制有异曲同工

的效果。

看完 SpringApplication 的初始化，接着跳回 run 方法继续分析

这里挑其中比较重要的几个方法进行分析

通过 getOrCreateEnvironment() 方法创建容器环境

可以看到 environment 存在则不会重复创建，当应用类型为servlet时创建的是 StandardServletEnvironment 对象，否则创建 StandardEnvironment 对象。

接着来看 configureEnvironment(environment, applicationArguments.getSourceArgs())

configurePropertySources(environment, args) 加载启动命令行的配置属性，来看一下实现

这里的 MutablePropertySources 对象用于存储配置集合，其内部维护了一个 CopyOnWriteArrayList 类型的list对象，当默认配置存在时，会向该list的尾部插入一个 new MapPropertySource("defaultProperties", this.defaultProperties) 对象。

接着来看 configureProfiles(environment, args)

这里主要做的事情就是获取 environment.getActiveProfiles() 的参数设置到 environment 中，即 spring.profiles.active 对应的环境变量。

最后来看一下 listeners.environmentPrepared(environment)

这里的 listeners 就是之前通过 META-INF/spring.factories 注册的所有listeners，后面我们先以其中最重要的 ConfigFileApplicationListener 做为例子进行分析，接着来看 listener.environmentPrepared(environment)

可以看到这里创建了一个 ApplicationEnvironmentPreparedEvent 类型的事件，并且调用了 multicastEvent 方法，通过该方法最终会调用到listener的 onApplicationEvent 方法，触发事件监听器的执行。

接下来具体看一下 ConfigFileApplicationListener 的 onApplicationEvent 方法做了什么

可以看到当监听到 ApplicationEnvironmentPreparedEvent 类型的事件时，调用 onApplicationEnvironmentPreparedEvent( (ApplicationEnvironmentPreparedEvent) event) 方法

可以看到这里通过 loadPostProcessors() 方法加载了 META-INF/spring.factories 中的所有 EnvironmentPostProcessor 类到list中，同时把 ConfigFileApplicationListener 自己也添加进去了。接着遍历list中所有对象，并执行 postProcessEnvironment 方法，于是接着来看该方法

这里的核心是 new Loader(environment, resourceLoader).load() ，这里的 Loader 是一个内部类，用于处理配置文件的加载，首先看一下其构造方法

可以看到这里的 resourceLoader 又是通过 SpringFactoriesLoader 进行加载，那么来看看 META-INF/spring.factories 中定义了哪些 resourceLoader

从名字就可以看出来， PropertiesPropertySourceLoader 和 YamlPropertySourceLoader 分别用于处理.properties和.yml类型的配置文件。

接着来看看 load() 方法做了什么

initializeProfiles() 进行了 profiles 的初始化，默认会添加 null 和 default 到 profiles 中， null 对应配置文件application.properties和application.yml， default 对应配置文件application-default.yml和application-default.properties，这里的 null 会被优先处理，由于后处理的会覆盖先处理的，因此其优先级最低。

接着来看 load(profile, this::getPositiveProfileFilter, addToLoaded(MutablePropertySources::addLast, false)) 方法

这里重点是通过 getSearchLocations() 获取配置文件的路径，默认会获得4个路径

接着会遍历这些路径，拼接配置文件名称，选择合适的yml或者properties解析器进行解析，最后将结果添加到 environment 的 propertySources 中。

可以看到这里也是根据 webApplicationType 的取值，分别创建不同的返回类型。

这里的 sources 装的就是我们的启动类，然后通过 load(context, sources.toArray(new Object[0])) 方法进行加载

来看一下 loader 是如何被加载的

经过一系列调用之后最终由 load(Class? source) 方法执行，这里比较有趣的是当Groovy存在时居然是优先调用Groovy的方式进行加载，否则才走 this.annotatedReader.register(source) 方法将启动类注册到 beanDefinitionMap 中。

这个 refresh() 方法相当重要，尤其是 invokeBeanFactoryPostProcessors(beanFactory) ，这是实现spring-boot-starter-*(mybatis、redis等)自动化配置的关键部分，后续再详细讲解。

至此Springboot的启动流程已经大体分析完了，也了解了配置文件和启动类分别是是如何被加载的，但仍有两个问题待解，一是Springboot的核心思想约定大于配置是如何做到的，二是Springboot的各种spring-boot-starter-*是如何发挥作用的，这两个问题留待后续文章继续分析。

Springboot自定义xml文件解析

有时候，要通过自定义XML配置文件来实现一些特定的功能。这里通过例子来说明。

首先，看部分spring加载bean文件的源码：

spring-beans-5.0.6.RELEASE.jar!/org/springframework/beans/factory/xml/PluggableSchemaResolver.class ：

spring-beans-5.0.6.RELEASE.jar!/org/springframework/beans/factory/xml/DefaultNamespaceHandlerResolver.class ：

可以看出，spring在加载xml文件的时候，会默认读取配置文件 META-INF/spring.schemas 和 META-INF/spring.handlers 。这样，我们就可以在这两个文件添加我们自定义的xml文件格式和xml文件解析处理器。

新建一个Springboot工程，pom如下。

SelfDefineXmlTrial/pom.xml ：

然后，新建一个用于测试controller。

com.lfqy.springboot.selfdefxml.controller.SelfDefXmlController ：

最后，创建一个Springboot的启动类。

com.lfqy.springboot.selfdefxml.SelfDefXmlApplication ：

运行启动之后，浏览器访问 效果如下：

修改前面提到的配置文件 META-INF/spring.schemas 、 META-INF/spring.handlers ，添加xml格式说明。

META-INF/spring.schemas ：

META-INF/spring.handlers ：

添加xml格式说明配置文件。

META-INF/selfdef.xsd ：

添加自定义xml格式处理器类。

com.lfqy.springboot.selfdefxml.selxmlparse.UserNamespaceHandler ：

新增xml格式解析类。

com.lfqy.springboot.selfdefxml.selxmlparse.UserBeanDefinitionParser ：

新增自定义xml对应的bean类。

com.lfqy.springboot.selfdefxml.beans.User ：

添加自定义xml配置文件读取的相关逻辑。

com.lfqy.springboot.selfdefxml.SelfDefXmlApplication ：

到这里，编码就完成了，工程的目录结构如下。

运行之后，控制台输出如下：

这里，通过实现一个启动时自动初始化的一个servlet来实现。

com.lfqy.springboot.selfdefxml.servlet.StartupServlet ：

在启动时加载servlet，为了方便区分，这里新写一个启动类。

com.lfqy.springboot.selfdefxml.SelfDefXmlLoadOnStartupApplication

到这里，编码已经完成，工程的目录结构如下：

运行之后，控制台输出如下：

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.zhihao.miao.springboot定义一个启动应用类（加上@SpringBootApplication注解）

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

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

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

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

启动并打印：

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

再看一个列子，

在上面的列子的相同包下（com.zhihao.miao.springboot）配置了People，并将其纳入到spring容器中（@Component），我们知道@SpringBootApplication注解会扫描当前包及其子包，所以People类会纳入到spring容器中去，我们需要将其排除在spring容器中，如何操作？

可以使用@SpringBootApplication的另外二个参数（exclude或excludeName）

启动类，

启动并打印结果：

然后修改@SpringBootApplication配置，

很明显启动报错。使用@excludeName注解也可以。如下，

@SpringBootApplication(excludeName = {"com.zhihao.miao.springboot.People"})

参考文档：

Springboot1.5.4官方文档

关于springboot源码解析和springboot源码编译的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。