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程序（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-*是如何发挥作用的，这两个问题留待后续文章继续分析。

---