SpringBoot笔记（一）核心内容

点击查看源网页

SpringBoot一站式开发

官网：https://spring.io/projects/spring-boot

Spring Boot可以轻松创建独立的、基于Spring的生产级应用程序，它可以让你“运行即可”。大多数Spring Boot应用程序只需要少量的Spring配置。

SpringBoot功能：

创建独立的Spring应用程序

直接嵌入Tomcat、Jetty或Undertow（无需部署WAR包，打包成Jar本身就是一个可以运行的应用程序）

提供一站式的“starter”依赖项，以简化Maven配置（需要整合什么框架，直接导对应框架的starter依赖）

尽可能自动配置Spring和第三方库（除非特殊情况，否则几乎不需要你进行什么配置）

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

没有代码生成，也没有XML配置的要求（XML是什么，好吃吗）

SpringBoot是现在最主流的开发框架，它提供了一站式的开发体验，大幅度提高了我们的开发效率。

走进SpringBoot

在SSM阶段，当我们需要搭建一个基于Spring全家桶的Web应用程序时，我们不得不做大量的依赖导入和框架整合相关的Bean定义，光是整合框架就花费了我们大量的时间，但是实际上我们发现，整合框架其实基本都是一些固定流程，我们每创建一个新的Web应用程序，基本都会使用同样的方式去整合框架，我们完全可以将一些重复的配置作为约定，只要框架遵守这个约定，为我们提供默认的配置就好，这样就不用我们再去配置了，约定优于配置！

而SpringBoot正是将这些过程大幅度进行了简化，它可以自动进行配置，我们只需要导入对应的启动器（starter）依赖即可。

完成本阶段的学习，基本能够胜任部分网站系统的后端开发工作，也建议同学们学习完SpringBoot之后寻找合适的队友去参加计算机项目相关的高校竞赛。

我们可以通过IDEA来演示如何快速创建一个SpringBoot项目，并且无需任何配置，就可以实现Bean注册。

SpringBoot项目文件结构

我们在创建SpringBoot项目之后，首先会自动生成一个主类，而主类中的main方法中调用了SpringApplication类的静态方法来启动整个SpringBoot项目，并且我们可以看到主类的上方有一个@SpringBootApplication注解：

同时还自带了一个测试类，测试类的上方仅添加了一个@SpringBootTest注解：

我们接着来看Maven中写了哪些内容：

除了以上这些文件以外，我们的项目目录下还有：

.gitignore - Git忽略名单，下一章我们会专门讲解Git版本控制。

application.properties - SpringBoot的配置文件，所有依赖的配置都在这里编写，但是一般情况下只需要配置必要项即可。

整合Web相关框架

我们来看一下，既然我们前面提到SpringBoot会内嵌一个Tomcat服务器，也就是说我们的Jar打包后，相当于就是一个可以直接运行的应用程序，我们来看一下如何创建一个SpringBootWeb项目。

这里我们演示使用IDEA来创建一个基于SpringBoot的Web应用程序。

它是真的快

创建完成后，直接开启项目，我们就可以直接访问：http://localhost:8080/，我们可以看到，但是由于我们没有编写任何的请求映射，所以没有数据。我们可以来看看日志：

我们可以看到，日志中除了最基本的SpringBoot启动日志以外，还新增了内嵌Web服务器（Tomcat）的启动日志，并且显示了当前Web服务器所开放的端口，并且自动帮助我们初始化了DispatcherServlet，但是我们只是创建了项目，导入了web相关的starter依赖，没有进行任何的配置，实际上它使用的是starter提供的默认配置进行初始化的。

由于SpringBoot是自动扫描的，因此我们直接创建一个Controller即可被加载：

我们几乎没有做任何配置，但是可以直接开始配置Controller，SpringBoot创建一个Web项目的速度就是这么快！

它还可以自动识别类型，如果我们返回的是一个对象类型的数据，那么它会自动转换为JSON数据格式，无需配置：

最后浏览器能够直接得到application/json的响应数据，就是这么方便。

修改Web相关配置

如果我们需要修改Web服务器的端口或是一些其他的内容，我们可以直接在application.properties中进行修改，它是整个SpringBoot的配置文件：

我们还可以编写自定义的配置项，并在我们的项目中通过@Value直接注入：

通过这种方式，我们就可以更好地将一些需要频繁修改的配置项写在配置文件中，并通过注解方式去获取值。

配置文件除了使用properties格式以外，还有一种叫做yaml格式，它的语法如下：

我们可以看到，每一级目录都是通过缩进（不能使用Tab，只能使用空格）区分，并且键和值之间需要添加冒号+空格来表示。

SpringBoot也支持这种格式的配置文件，我们可以将application.properties修改为application.yml或是application.yaml来使用YAML语法编写配置：

整合SpringSecurity依赖

我们接着来整合一下SpringSecurity依赖，继续感受SpringBoot带来的光速开发体验，只需要导入SpringSecurity的Starter依赖即可：

导入依赖后，我们直接启动SpringBoot应用程序，可以发现SpringSecurity已经生效了。

并且SpringSecurity会自动为我们生成一个默认用户user，它的密码会出现在日志中：

其中ff24bee3-e1b7-4309-9609-d32618baf5cb就是随机生成的一个密码，我们可以使用此用户登录。

我们也可以在配置文件中直接配置：

实际上这样的配置方式就是一个inMemoryAuthentication，只是我们可以直接配置而已。

当然，页面的控制和数据库验证我们还是需要提供WebSecurityConfigurerAdapter的实现类去完成：

注意这里不需要再添加@EnableWebSecurity了，因为starter依赖已经帮我们添加了。

使用了SpringBoot之后，我们发现，需要什么功能，只需要导入对应的starter依赖即可，甚至都不需要你去进行额外的配置，你只需要关注依赖本身的必要设置即可，大大提高了我们的开发效率。

整合Mybatis框架

我们接着来看如何整合Mybatis框架，同样的，我们只需要导入对应的starter依赖即可：

导入依赖后，直接启动会报错，是因为有必要的配置我们没有去编写，我们需要指定数据源的相关信息：

再次启动，成功。

我们发现日志中会出现这样一句话：

这是Mybatis自动扫描输出的语句，导入依赖后，我们不需要再去设置Mybatis的相关Bean了，也不需要添加任何@MapperSacn注解，因为starter已经帮助我们做了，它会自动扫描项目中添加了@Mapper注解的接口，直接将其注册为Bean，不需要进行任何配置。

当然，如果你觉得每个接口都去加一个@Mapper比较麻烦的话也可以用回之前的方式，直接@MapperScan使用包扫描。

添加Mapper之后，使用方法和SSM阶段是一样的，我们可以将其与SpringSecurity结合使用：

最后配置一下自定义验证即可，注意这样之前配置文件里面配置的用户就失效了：

在首次使用时，我们发现日志中输出以以下语句：

实际上，SpringBoot会自动为Mybatis配置数据源，默认使用的就是HikariCP数据源。

整合Thymeleaf框架

整合Thymeleaf也只需导入对应的starter即可：

接着我们只需要直接使用即可：

但是注意，这样只能正常解析HTML页面，但是js、css等静态资源我们需要进行路径指定，不然无法访问，我们在配文件中配置一下静态资源的访问前缀：

接着我们像之前一样，把登陆页面实现一下吧。

日志系统

SpringBoot为我们提供了丰富的日志系统，它几乎是开箱即用的。

日志门面和日志实现

我们首先要区分一下，什么是日志门面（Facade）什么是日志实现，我们之前学习的JUL实际上就是一种日志实现，我们可以直接使用JUL为我们提供的日志框架来规范化打印日志，而日志门面，如Slf4j，是把不同的日志系统的实现进行了具体的抽象化，只提供了统一的日志使用接口，使用时只需要按照其提供的接口方法进行调用即可，由于它只是一个接口，并不是一个具体的可以直接单独使用的日志框架，所以最终日志的格式、记录级别、输出方式等都要通过接口绑定的具体的日志系统来实现，这些具体的日志系统就有log4j、logback、java.util.logging等，它们才实现了具体的日志系统的功能。

日志门面和日志实现就像JDBC和数据库驱动一样，一个是画大饼的，一个是真的去做饼的。

img

但是现在有一个问题就是，不同的框架可能使用了不同的日志框架，如果这个时候出现众多日志框架并存的情况，我们现在希望的是所有的框架一律使用日志门面（Slf4j）进行日志打印，这时该怎么去解决？我们不可能将其他框架依赖的日志框架替换掉，直接更换为Slf4j吧，这样显然不现实。

这时，可以采取类似于偷梁换柱的做法，只保留不同日志框架的接口和类定义等关键信息，而将实现全部定向为Slf4j调用。相当于有着和原有日志框架一样的外壳，对于其他框架来说依然可以使用对应的类进行操作，而具体如何执行，真正的内心已经是Slf4j的了。

img

所以，SpringBoot为了统一日志框架的使用，做了这些事情：

直接将其他依赖以前的日志框架剔除

导入对应日志框架的Slf4j中间包

导入自己官方指定的日志实现，并作为Slf4j的日志实现层

在SpringBoot中打印日志信息

SpringBoot使用的是Slf4j作为日志门面，Logback（Logback 是log4j 框架的作者开发的新一代日志框架，它效率更高、能够适应诸多的运行环境，同时天然支持SLF4J）作为日志实现，对应的依赖为：

此依赖已经被包含了，所以我们如果需要打印日志，可以像这样：

因为我们使用了Lombok，所以直接一个注解也可以搞定哦：

日志级别从低到高分为TRACE < DEBUG < INFO < WARN < ERROR < FATAL，SpringBoot默认只会打印INFO以上级别的信息。

配置Logback日志

Logback官网：https://logback.qos.ch

和JUL一样，Logback也能实现定制化，我们可以编写对应的配置文件，SpringBoot推荐将配置文件名称命名为logback-spring.xml表示这是SpringBoot下Logback专用的配置，可以使用SpringBoot 的高级Proﬁle功能，它的内容类似于这样：

最外层由configuration包裹，一旦编写，那么就会替换默认的配置，所以如果内部什么都不写的话，那么会导致我们的SpringBoot项目没有配置任何日志输出方式，控制台也不会打印日志。

我们接着来看如何配置一个控制台日志打印，我们可以直接导入并使用SpringBoot为我们预设好的日志格式，在org/springframework/boot/logging/logback/defaults.xml中已经帮我们把日志的输出格式定义好了，我们只需要设置对应的appender即可：

导入后，我们利用预设的日志格式创建一个控制台日志打印：

配置完成后，我们发现控制台已经可以正常打印日志信息了。

接着我们来看看如何开启文件打印，我们只需要配置一个对应的Appender即可：

配置完成后，我们可以看到日志文件也能自动生成了。

我们也可以魔改官方提供的日志格式，官方文档：https://logback.qos.ch/manual/layouts.html

这里需要提及的是MDC机制，Logback内置的日志字段还是比较少，如果我们需要打印有关业务的更多的内容，包括自定义的一些数据，需要借助logback MDC机制，MDC为“Mapped Diagnostic Context”（映射诊断上下文），即将一些运行时的上下文数据通过logback打印出来；此时我们需要借助org.sl4j.MDC类。

比如我们现在需要记录是哪个用户访问我们网站的日志，只要是此用户访问我们网站，都会在日志中携带该用户的ID，我们希望每条日志中都携带这样一段信息文本，而官方提供的字段无法实现此功能，这时就需要使用MDC机制：

通过这种方式，我们就可以向日志中传入自定义参数了，我们日志中添加这样一个占位符%X{键值}，名字保持一致：

这样当我们向MDC中添加信息后，只要是当前线程（本质是ThreadLocal实现）下输出的日志，都会自动替换占位符。

自定义Banner

我们在之前发现，实际上Banner部分和日志部分是独立的，SpringBoot启动后，会先打印Banner部分，那么这个Banner部分是否可以自定义呢？答案是可以的。

我们可以直接来配置文件所在目录下创建一个名为banner.txt的文本文档，内容随便你：

可以使用在线生成网站进行生成自己的个性Banner：https://www.bootschool.net/ascii

我们甚至还可以使用颜色代码来为文本切换颜色：

也可以获取一些常用的变量信息：

玩的开心！

多环境配置

在日常开发中，我们项目会有多个环境。例如开发环境（develop）也就是我们研发过程中疯狂敲代码修BUG阶段，生产环境（production ）项目开发得差不多了，可以放在服务器上跑了。不同的环境下，可能我们的配置文件也存在不同，但是我们不可能切换环境的时候又去重新写一次配置文件，所以我们可以将多个环境的配置文件提前写好，进行自由切换。

由于SpringBoot只会读取application.properties或是application.yml文件，那么怎么才能实现自由切换呢？SpringBoot给我们提供了一种方式，我们可以通过配置文件指定：

接着我们分别创建两个环境的配置文件，application-dev.yml和application-prod.yml分别表示开发环境和生产环境的配置文件，比如开发环境我们使用的服务器端口为8080，而生产环境下可能就需要设置为80或是443端口，那么这个时候就需要不同环境下的配置文件进行区分：

这样我们就可以灵活切换生产环境和开发环境下的配置文件了。

SpringBoot自带的Logback日志系统也是支持多环境配置的，比如我们想在开发环境下输出日志到控制台，而生产环境下只需要输出到文件即可，这时就需要进行环境配置：

注意springProfile是区分大小写的！

那如果我们希望生产环境中不要打包开发环境下的配置文件呢，我们目前虽然可以切换开发环境，但是打包的时候依然是所有配置文件全部打包，这样总感觉还欠缺一点完美，因此，打包的问题就只能找Maven解决了，Maven也可以设置多环境：

接着，我们需要根据环境的不同，排除其他环境的配置文件：

接着，我们可以直接将Maven中的environment属性，传递给SpringBoot的配置文件，在构建时替换为对应的值：

这样，根据我们Maven环境的切换，SpringBoot的配置文件也会进行对应的切换。

最后我们打开Maven栏目，就可以自由切换了，直接勾选即可，注意切换环境之后要重新加载一下Maven项目，不然不会生效！

打包运行

现在我们的SpringBoot项目编写完成了，那么如何打包运行呢？非常简单，只需要点击Maven生命周期中的package即可，它会自动将其打包为可直接运行的Jar包，第一次打包可能会花费一些时间下载部分依赖的源码一起打包进Jar文件。

我们发现在打包的过程中还会完整的将项目跑一遍进行测试，如果我们不想测试直接打包，可以手动使用以下命令：

打包后，我们会直接得到一个名为springboot-study-0.0.1-SNAPSHOT.jar的文件，这时在CMD窗口中输入命令：

输入后，可以看到我们的Java项目成功运行起来了，如果手动关闭窗口会导致整个项目终止运行。

再谈Spring框架

注意： 开始本部分前，建议先完成SSM阶段的Spring源码讲解部分。

我们在SpringBoot阶段，需要继续扩充Spring框架的相关知识，来巩固和强化对于Spring框架的认识。

任务调度

为了执行某些任务，我们可能需要一些非常规的操作，比如我们希望使用多线程来处理我们的结果或是执行一些定时任务，到达指定时间再去执行。

这时我们首先想到的就是创建一个新的线程来处理，或是使用TimerTask来完成定时任务，但是我们有了Spring框架之后，就不用这样了，因为Spring框架为我们提供了更加便捷的方式进行任务调度。

异步任务

需要使用Spring异步任务支持，我们需要在配置类上添加@EnableAsync或是在SpringBoot的启动类上添加也可以。

接着我们只需要在需要异步执行的方法上，添加@Async注解即可将此方法标记为异步，当此方法被调用时，会异步执行，也就是新开一个线程执行，不是在当前线程执行。

实际上这也是得益于AOP机制，通过线程池实现，但是也要注意，正是因为它是AOP机制的产物，所以它只能是在Bean中才会生效！

使用 @Async 注释的方法可以返回 ‘void’ 或 “Future” 类型，Future是一种用于接收任务执行结果的一种类型，我们会在Java并发编程中进行讲解，这里暂时不做介绍。

定时任务

看完了异步任务，我们接着来看定时任务，定时任务其实就是指定在哪个时候再去执行，在JavaSE阶段我们使用过TimerTask来执行定时任务。

Spring中的定时任务是全局性质的，当我们的Spring程序启动后，那么定时任务也就跟着启动了，我们可以在配置类上添加@EnableScheduling或是在SpringBoot的启动类上添加也可：

接着我们可以创建一个定时任务配置类，在配置类里面编写定时任务：

我们注意到@Scheduled中有很多参数，我们需要指定’cron’, ‘fixedDelay(String)’, or ’fixedRate(String)’的其中一个，否则无法创建定时任务，他们的区别如下：

fixedDelay：在上一次定时任务执行完之后，间隔多久继续执行。

fixedRate：无论上一次定时任务有没有执行完成，两次任务之间的时间间隔。

cron：使用cron表达式来指定任务计划。

这里重点讲解一下cron表达式：https://blog.csdn.net/sunnyzyq/article/details/98597252

监听器

监听器对我们来说也是一个比较陌生的概念，那么何谓监听呢？

监听实际上就是等待某个事件的触发，当事件触发时，对应事件的监听器就会被通知。

通过监听事件，我们就可以在对应的时机进行一些额外的处理，我们可以通过断点调试来查看一个事件是如何发生，以及如何通知监听器的。

通过阅读源码，我们得知，一个事件实际上就是通过publishEvent方法来进行发布的，我们也可以自定义我们自己项目中的事件，并注册对应的监听器进行处理。

这样，我们就实现了自定义事件发布和监听。

Aware系列接口

我们在之前讲解Spring源码时，经常会发现某些类的定义上，除了我们当时讲解的继承关系以外，还实现了一些接口，他们的名称基本都是xxxxAware，比如我们在讲解SpringSecurity的源码中，AbstractAuthenticationProcessingFilter类就是这样：

我们发现它除了继承自GenericFilterBean之外，还实现了ApplicationEventPublisherAware和MessageSourceAware接口，那么这些Aware接口到底是干嘛的呢？

Aware的中文意思为感知。简单来说，他就是一个标识，实现此接口的类会获得某些感知能力，Spring容器会在Bean被加载时，根据类实现的感知接口，会调用类中实现的对应感知方法。

比如AbstractAuthenticationProcessingFilter就实现了ApplicationEventPublisherAware接口，此接口的感知功能为事件发布器，在Bean加载时，会调用实现类中的setApplicationEventPublisher方法，而AbstractAuthenticationProcessingFilter类则利用此方法，在Bean加载阶段获得了容器的事件发布器，以便之后发布事件使用。

同样的，除了ApplicationEventPublisherAware接口外，我们再来演示一个接口，比如：

BeanNameAware就是感知Bean名称的一个接口，当Bean被加载时，会调用setBeanName方法并将Bean名称作为参数传递。

有关所有的Aware这里就不一一列举了。

探究SpringBoot实现原理

注意： 难度较大，本版块作为选学内容，在开始前，必须完成SSM阶段源码解析部分的学习。

我们在前面的学习中切实感受到了SpringBoot为我们带来的便捷，那么它为何能够实现如此快捷的开发模式，starter又是一个怎样的存在，它是如何进行自动配置的，我们现在就开始研究。

启动原理

首先我们来看看，SpringBoot项目启动之后，做了什么事情，SpringApplication中的静态run方法：

套娃如下：

我们发现，这里直接new了一个新的SpringApplication对象，传入我们的主类作为构造方法参数，并调用了非static的run方法，我们先来看看构造方法里面做了什么事情：

关键就在这里了，它是如何知道哪些类是ApplicationContextInitializer的实现类的呢？

这里就要提到spring.factories了，它是 Spring 仿造Java SPI实现的一种类加载机制。它在 META-INF/spring.factories 文件中配置接口的实现类名称，然后在程序中读取这些配置文件并实例化。这种自定义的SPI机制是 Spring Boot Starter 实现的基础。

SPI的常见例子：

数据库驱动加载接口实现类的加载：JDBC加载不同类型数据库的驱动

日志门面接口实现类加载：SLF4J加载不同提供商的日志实现类

说白了就是人家定义接口，但是实现可能有很多种，但是核心只提供接口，需要我们按需选择对应的实现，这种方式是高度解耦的。

我们来看看getSpringFactoriesInstances方法做了什么：

其中SpringFactoriesLoader.loadFactoryNames正是读取配置的核心部分，我们后面还会遇到。

接着我们来看run方法里面做了什么事情。

我们发现，实际上SpringBoot就是Spring的一层壳罢了，离不开最关键的ApplicationContext，也就是说，在启动后会自动配置一个ApplicationContext，只不过是进行了大量的扩展。

我们来看ApplicationContext是怎么来的，打开createApplicationContext方法：

我们发现在构造方法中applicationContextFactory直接使用的是DEFAULT：

DEFAULT是直接编写的一个匿名内部类，其实已经很明确了，正是根据webApplicationType类型进行判断，如果是SERVLET，那么久返回专用于Web环境的AnnotationConfigServletWebServerApplicationContext对象（SpringBoot中新增的），否则返回普通的AnnotationConfigApplicationContext对象，也就是到这里为止，Spring的容器就基本已经确定了。

注意AnnotationConfigApplicationContext是Spring框架提供的类，从这里开始相当于我们在讲Spring的底层源码了，我们继续深入，AnnotationConfigApplicationContext对象在创建过程中会创建AnnotatedBeanDefinitionReader，它是用于通过注解解析Bean定义的工具类：

其构造方法：

回到SpringBoot，我们最后来看，prepareContext方法中又做了什么事情：

因此，在prepareContext执行完成之后，我们的主类成功完成Bean注册，接下来，就该类上注解大显身手了。

自动配置原理

既然主类已经在初始阶段注册为Bean，那么在加载时，就会根据注解定义，进行更多的额外操作。所以我们来看看主类上的@SpringBootApplication注解做了什么事情。

我们发现，@SpringBootApplication上添加了@ComponentScan注解，此注解我们此前已经认识过了，但是这里并没有配置具体扫描的包，因此它会自动将声明此接口的类所在的包作为basePackage，因此当添加@SpringBootApplication之后也就等于直接开启了自动扫描，但是一定注意不能在主类之外的包进行Bean定义，否则无法扫描到，需要手动配置。

接着我们来看第二个注解@EnableAutoConfiguration，它就是自动配置的核心了，我们来看看它是如何定义的：

老套路了，直接一手@Import，通过这种方式来将一些外部的Bean加载到容器中。我们来看看AutoConfigurationImportSelector做了什么事情：

我们看到它实现了很多接口，包括大量的Aware接口，实际上就是为了感知某些必要的对象，并将其存到当前类中。

其中最核心的是DeferredImportSelector接口，它是ImportSelector的子类，它定义了selectImports方法，用于返回需要加载的类名称，在Spring加载ImportSelector类型的Bean时，会调用此方法来获取更多需要加载的类，并将这些类一并注册为Bean：

到目前为止，我们了解了两种使用@Import有特殊机制的接口：ImportSelector（这里用到的）和ImportBeanDefinitionRegistrar（之前Mybatis-spring源码有讲）当然还有普通的@Configuration配置类。

我们可以来阅读一下ConfigurationClassPostProcessor的源码，看看它到底是如何处理@Import的：

我们接着来看，ConfigurationClassParser是如何进行解析的：

最后我们再来看最核心的doProcessConfigurationClass方法：

不难注意到，虽然这里额外处理了ImportSelector对象，但是还针对ImportSelector的子接口DeferredImportSelector进行了额外处理，Deferred是延迟的意思，它是一个延迟执行的ImportSelector，并不会立即进处理，而是丢进DeferredImportSelectorHandler，并且在parse方法的最后进行处理：

我们接着来看DeferredImportSelector正好就有一个process方法：

最后经过ConfigurationClassParser处理完成后，通过parser.getConfigurationClasses()就能得到通过配置类导入了哪些额外的配置类。最后将这些配置类全部注册BeanDefinition，然后就可以交给接下来的Bean初始化过程去处理了。

最后我们再去看loadBeanDefinitions是如何运行的：

这样，整个@Configuration配置类的底层配置流程我们就大致了解了。接着我们来看AutoConfigurationImportSelector是如何实现自动配置的，可以看到内部类AutoConfigurationGroup的process方法，它是父接口的实现，因为父接口是DeferredImportSelector，那么很容易得知，实际上最后会调用process方法获取所有的自动配置类：

我们接着来看getAutoConfigurationEntry方法：

注意这里并不是spring.factories文件中所有的自动配置类都会被加载，它会根据@Condition注解的条件进行加载。这样就能实现我们需要什么模块添加对应依赖就可以实现自动配置了。

所有的源码看不懂，都源自于你的心中没有形成一个完整的闭环！一旦一条线推到头，闭环形成，所有疑惑迎刃而解。

自定义Starter

我们仿照Mybatis来编写一个自己的starter，Mybatis的starter包含两个部分：

因此我们也将我们自己的starter这样设计：

我们设计三个模块：

spring-boot-hello：基础业务功能模块

spring-boot-starter-hello：启动器

spring-boot-autoconifgurer-hello：自动配置依赖

首先是基础业务功能模块，这里我们随便创建一个类就可以了：

启动器主要做依赖管理，这里就不写任何代码，只写pom文件：

导入autoconfigurer模块作为依赖即可，接着我们去编写autoconfigurer模块，首先导入依赖：

接着创建一个HelloWorldAutoConfiguration作为自动配置类：

对应的配置读取类：

最后再编写spring.factories文件，并将我们的自动配置类添加即可：

最后再Maven根项目执行install安装到本地仓库，完成。接着就可以在其他项目中使用我们编写的自定义starter了。

Runner接口

在项目中，可能会遇到这样一个问题：我们需要在项目启动完成之后，紧接着执行一段代码。

我们可以编写自定义的ApplicationRunner来解决，它会在项目启动完成后执行：

当然也可以使用CommandLineRunner，它也支持使用@Order或是实现Ordered接口来支持优先级执行。

实际上它就是run方法的最后：

下一章，我们将继续讲解几乎程序员必会的Git版本控制。