【基础篇】二、parent继承、starter、引导类、内嵌tomcat

0、前言

SpringBoot，Boot，鞋子，其设计目的是用来简化Spring框架应用的初始搭建以及开发过程

Spring程序缺点：

• 依赖设置繁琐（各个依赖之间版本的适配、依赖排除等活儿得自己调）
• 配置繁琐

SpringBoot程序优点：

• 起步依赖（简化依赖配置）
• 自动配置（简化常用工程相关配置）
• 辅助功能（内置服务器，……）

关于这三点，接下来分开说明。

1、继承parent

日常开发中，可能出现：有一个项目，里面两个模块都引用了以下相同的依赖：

首先想到的优化方案应该是，抽取一个公共的pom，再由这两个pom引入依赖：

再优化，公共的这个pom再拆，一个做版本管理，一个做依赖管理，这就是parent的雏形：

有了以上这个概念，再来看SpringBoot工程中的pom.xml文件，发现有一个spring-boot-starter-parent的Maven依赖继承：

跟进这个继承：

继续跟进，发现这里定义好了一系列的版本号（SpringBoot已经给user搭配好的一套依赖，使用2.6.11的SpringBoot，那底层搭配好的依赖的版本就是这些）：

疑问：即使这里版本号已经有了，那也应该在自己的项目里dollar大括号取一下，为何可以直接写Maven的GA信息，而不要version坐标？

<dependency>
	<groupId>org.springframework.bootgroupId>
	<artifactId>spring-boot-starter-webartifactId>
dependency>

继续往下翻就会发现，这里不仅定义好了各个依赖的版本，还定义了依赖管理dependencyManagement，这就是我们不加坐标就能引入的原因：

细看使用阿里云版本的SpringBoot工程，发现并没有这个parent继承，但它在这里直接导入了SpringBoot的依赖配置，官网下创建的工程采用继承，阿里云下创建的则直接导入 ，效果都一样，不同形式而已。

到这儿，也可以得出结论，你所需要的那些依赖的版本，取决于SpringBoot的版本

小结：

• 继承parent模块可以避免多个依赖使用相同技术时出现依赖版本冲突（版本的统一化管理）
• 继承parent的形式也可以采用引入依赖的形式实现效果

2、starter

一个starter的背后，包含了若干依赖，简单说就是你导入一个starter，相当于导入了好几个甚至几十个依赖，还是别人已经调好版本号的一组依赖。比如创建项目时勾选了Spring web而引入的spring-boot-starter-web，Ctrl跟进一下发现，它里面有spring-mvc、starter-tomcat等等：

如此，通过Maven依赖，就可以用一个starter来完成很多事。

starter是SpringBoot的常见项目名称，定义了当前项目于使用的所有依赖坐标，以达到减少依赖配置的目的。

注意starter和parent继承的关系：starter引入以后，starter背后的依赖就会传递给你的项目。但parent只是定义了若干个坐标版本号（做依赖管理，而不是依赖，即用不用随你，但你要是用的话，可以使用我搭配好的这个版本号），parent只是用来减少依赖冲突的！！！ 一个是把饭直接喂你嘴里，一个是写了张纸条，告诉你饭在冰箱，别乱找东西吃。因此，在实际开发中：

• 引入任意坐标时，使用Maven的GAV中的GA即可，除非SpringBoot未提供对应的版本V
• 如发生坐标错误，再自己指定Version（小心依赖的版本冲突）

starter的小结：

• 开发SpringBoot程序需要导入坐标时通常导入对应的starter
• 每个不同的starter根据功能不同，通常包含多个依赖坐标（依赖传递）
• 使用starter可以实现快速配置的效果，达到简化配置的目的

3、引导类

@SpringBootApplication
public class Springboot01QuickstartApplication {
	public static void main(String[] args) {
		SpringApplication.run(Springboot01QuickstartApplication.class, args);
	}
}

• SpringBoot的引导类是Boot工程的执行入口，运行main方法就可以启动项目
• SpringBoot工程运行后初始化Spring容器，扫描并加载引导类所在包路径下的bean

另外，run方法的返回值是一个ConfigurableApplicationContext，其最上层父类就是ApplicationContext -> BeanFactory：

因此，可以直接在这里通过IoC容器获取Bean（后面源码篇再整理）：

4、内嵌tomcat

看之前创建项目时勾选spring-web而导入的依赖spring-boot-starter-web，跟进看到tomcat的起步依赖：

再跟进，看下tomcat starter背后的依赖，有个tomcat-embed-core，即tomcat的内嵌核心…

排除掉tomcat的starter，看下没有tomcat服务器的启动效果：

此时再调接口，自然不能响应了。在引入一个别的web服务器的起步依赖：

此时一切正常，控制台可看到内置jetty服务器的信息。最后，关于SpringBoot中内置的三款web服务器：

• tomcat(默认)：apache出品，粉丝多，应用面广，负载了若干较重的组件
• jetty：更轻量级，负载性能远不及tomcat
• undertow：负载性能勉强跑赢tomcat

变更内嵌服务器思想是去除现有服务器，添加全新的服务器。

内嵌Tomcat工作原理是将Tomcat服务器作为对象运行，并将该对象交给Spring容器管理

5、SpringBoot项目快速启动

前后端每次联调，若都等待后端来启动服务，则很不方便，而SpringBoot项目支持快速启动，拿着jar包在JDK环境下就能运行：

STEP1：对SpringBoot项目打包，mvn package

STEP2：在target目录下找到jar包

STEP3：打开DOS窗口，执行启动指令：java -jar xxx.jar

STEP4：测下效果

---

注意，不是所有的jar包都可以这样快速启动，上面成功是因为SpringBoot对应的maven插件，生成了一个Fat-jar，具体原理看这篇【SpringBoot-Q5】