目录
一、简介
1.1、什么是SpringBoot
1.2.、特性
1.3、四大核心
1.4、特点
二、快速入门
2.1、开发流程
2.1.1、创建项目
maven项目
2.1.2、导入场景
场景启动器
2.1.3、主程序
2.1.4、业务
三、Spring Initializr 创建向导
3.1、依赖管理机制
3.1.1、为什么导入starter-web所有相关依赖都导入进来?
3.1.2、为什么版本号不用写?
3.1.3、自定义版本号
3.1.4、第三方的jar包
四、自动配置机制
4.1、 初步理解
4.2、 完整流程
一、简介
1.1、什么是SpringBoot
我们知道,从 2002 年开始,Spring 一直在飞速的发展,如今已经成为了在Java EE(Java Enterprise Edition)开发中真正意义上的标准,但是随着技术的发展,Java EE使用 Spring 逐渐变得笨重起来,大量的 XML 文件存在于项目之中。繁琐的配置,整合第三方框架的配置问题,导致了开发和部署效率的降低。
2012 年 10 月,Mike Youngstrom 在 Spring jira 中创建了一个功能请求,要求在 Spring 框架中支持无容器 Web 应用程序体系结构。他谈到了在主容器引导 spring 容器内配置 Web 容器服务。这是 jira 请求的摘录:
我认为 Spring 的 Web 应用体系结构可以大大简化,如果它提供了从上到下利用 Spring 组件和配置模型的工具和参考体系结构。在简单的 main()方法引导的 Spring 容器内嵌入和统一这些常用Web 容器服务的配置。
这一要求促使了 2013 年初开始的 Spring Boot 项目的研发,到今天,Spring Boot 的版本已经到了 2.0.3 RELEASE。Spring Boot 并不是用来替代 Spring 的解决方案,而是和 Spring 框架紧密结合用于提升 Spring 开发者体验的工具。
它集成了大量常用的第三方库配置,Spring Boot应用中这些第三方库几乎可以是零配置的开箱即用(out-of-the-box),大部分的 Spring Boot 应用都只需要非常少量的配置代码(基于 Java 的配置),开发者能够更加专注于业务逻辑。
1.2.、特性
- 快速创建独立 Spring 应用
- SSM:导包、写配置、启动运行
- 直接嵌入Tomcat、Jetty or Undertow(无需部署 war 包)【Servlet容器】
- linux java tomcat mysql: war 放到 tomcat 的 webapps下
- jar: java环境; java -jar
- 重点:提供可选的starter,简化应用整合
- 场景启动器(starter):web、json、邮件、oss(对象存储)、异步、定时任务、缓存...
- 导包一堆,控制好版本。
- 为每一种场景准备了一个依赖; web-starter。mybatis-starter
- 重点:按需自动配置 Spring 以及 第三方库
- 如果这些场景我要使用(生效)。这个场景的所有配置都会自动配置好。
- 约定大于配置:每个场景都有很多默认配置。
- 自定义:配置文件中修改几项就可以
- 提供生产级特性:如 监控指标、健康检查、外部化配置等
- 监控指标、健康检查(k8s)、外部化配置
- 无代码生成、无xml
1.3、四大核心
自动配置、起步依赖、Actuator、命令行界面
1.4、特点
简化开发,简化配置,简化整合,简化部署,简化监控,简化运维。
二、快速入门
2.1、开发流程
2.1.1、创建项目
maven项目
<!-- 所有springboot项目都必须继承自 spring-boot-starter-parent -->
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>3.0.5</version>
</parent>
2.1.2、导入场景
场景启动器
<dependencies>
<!-- web开发的场景启动器 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
2.1.3、主程序
@SpringBootApplication //这是一个SpringBoot应用
public class MainApplication {
public static void main(String[] args) {
SpringApplication.run(MainApplication.class,args);
}
}
2.1.4、业务
@RestController
public class HelloController {
@GetMapping("/hello")
public String hello(){
return "Hello,Spring Boot 3!";
}
}
2.1.5、测试
默认启动访问:localhost:8080
三、Spring Initializr 创建向导
一键创建好整个项目结构
3.1、依赖管理机制
3.1.1、为什么导入starter-web所有相关依赖都导入进来?
- 开发什么场景,导入什么场景启动器。
- maven依赖传递原则。A-B-C: A就拥有B和C
- 导入 场景启动器。 场景启动器 自动把这个场景的所有核心依赖全部导入进来
3.1.2、为什么版本号不用写?
- 每个boot项目都有一个父项目
spring-boot-starter-parent
- parent的父项目是
spring-boot-dependencies
- 父项目 版本仲裁中心,把所有常见的jar的依赖版本都声明好了。
- 比如:
mysql-connector-j
3.1.3、自定义版本号
-
利用maven的就近原则
-
直接在当前项目properties标签中声明父项目用的版本属性的key
-
直接在导入依赖的时候声明版本
-
3.1.4、第三方的jar包
- boot父项目没有管理的需要自行声明好
<!-- https://mvnrepository.com/artifact/com.alibaba/druid -->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
<version>1.2.16</version>
</dependency>
四、自动配置机制
4.1、 初步理解
- 自动配置的Tomcat、SpringMVC等
- 导入场景,容器中就会自动配置好这个场景的核心组件。
- 以前:DispatcherServlet、ViewResolver、CharacterEncodingFilter……
- 现在:自动配置好的这些组件
- 验证:容器中有了什么组件,就具有什么功能
public static void main(String[] args) {
//java10: 局部变量类型的自动推断
var ioc = SpringApplication.run(MainApplication.class, args);
//1、获取容器中所有组件的名字
String[] names = ioc.getBeanDefinitionNames();
//2、挨个遍历:
// dispatcherServlet、beanNameViewResolver、characterEncodingFilter、multipartResolver
// SpringBoot把以前配置的核心组件现在都给我们自动配置好了。
for (String name : names) {
System.out.println(name);
}
}
- 默认的包扫描规则
-
@SpringBootApplication
标注的类就是主程序类- SpringBoot只会扫描主程序所在的包及其下面的子包,自动的component-scan功能
- 自定义扫描路径
-
-
- @SpringBootApplication(scanBasePackages = "com.atguigu")
@ComponentScan("com.atguigu")
直接指定扫描的路径
-
- 配置默认值
-
- 配置文件的所有配置项是和某个类的对象值进行一一绑定的。
- 绑定了配置文件中每一项值的类: 属性类。
- 比如:
ServerProperties
绑定了所有Tomcat服务器有关的配置- ....参照官方文档:或者参照 绑定的 属性类。
MultipartProperties
绑定了所有文件上传相关的配置
- 按需加载自动配置
- 导入场景
spring-boot-starter-web
- 场景启动器除了会导入相关功能依赖,导入一个
spring-boot-starter
,是所有starter
的starter
,基础核心starter spring-boot-starter
导入了一个包spring-boot-autoconfigure
。包里面都是各种场景的AutoConfiguration
自动配置类- 虽然全场景的自动配置都在
spring-boot-autoconfigure
这个包,但是不是全都开启的。- 导入哪个场景就开启哪个自动配置
- 场景启动器除了会导入相关功能依赖,导入一个
- 导入场景
总结: 导入场景启动器、触发 spring-boot-autoconfigure
这个包的自动配置生效、容器中就会具有相关场景的功能
4.2、 完整流程
自动配置流程细节梳理:
1、导入starter-web
:导入了web开发场景
- 1、场景启动器导入了相关场景的所有依赖:
starter-json
、starter-tomcat
、springmvc
- 2、每个场景启动器都引入了一个
spring-boot-starter
,核心场景启动器。 - 3、核心场景启动器引入了
spring-boot-autoconfigure
包。 - 4、
spring-boot-autoconfigure
里面囊括了所有场景的所有配置。 - 5、只要这个包下的所有类都能生效,那么相当于SpringBoot官方写好的整合功能就生效了。
- 6、SpringBoot默认却扫描不到
spring-boot-autoconfigure
下写好的所有配置类。(这些配置类给我们做了整合操作),默认只扫描主程序所在的包。
2、主程序:@SpringBootApplication
- 1、
@SpringBootApplication
由三个注解组成@SpringBootConfiguration
、@EnableAutoConfiguratio
、@ComponentScan
- 2、SpringBoot默认只能扫描自己主程序所在的包及其下面的子包,扫描不到
spring-boot-autoconfigure
包中官方写好的配置类 - 3、
@EnableAutoConfiguration
:SpringBoot 开启自动配置的核心。
-
- 1. 是由
@Import(AutoConfigurationImportSelector.class)
提供功能:批量给容器中导入组件。 - 2. SpringBoot启动会默认加载 142个配置类。
- 3. 这142个配置类来自于
spring-boot-autoconfigure
下META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
文件指定的 - 项目启动的时候利用 @Import 批量导入组件机制把
autoconfigure
包下的142xxxxAutoConfiguration
类导入进来(自动配置类) - 虽然导入了
142
个自动配置类
- 1. 是由
- 4、按需生效:
- 并不是这
142
个自动配置类都能生效 - 每一个自动配置类,都有条件注解
@ConditionalOnxxx
,只有条件成立,才能生效
- 并不是这
3、xxxxAutoConfiguration
自动配置类
- 1、给容器中使用@Bean 放一堆组件。
- 2、每个自动配置类都可能有这个注解
@EnableConfigurationProperties(ServerProperties.class)
,用来把配置文件中配的指定前缀的属性值封装到xxxProperties
属性类中 - 3、以Tomcat为例:把服务器的所有配置都是以
server
开头的。配置都封装到了属性类中。 - 4、给容器中放的所有组件的一些核心参数,都来自于
xxxProperties
。xxxProperties
都是和配置文件绑定。 - 只需要改配置文件的值,核心组件的底层参数都能修改
4、写业务,全程无需关心各种整合(底层这些整合写好了,而且也生效了)。