Introduction
我们知道, SpringBoot 之所以强大, 就是因为他提供了各种默认的配置, 可以让我们在集成各个组件的时候从各种各样的配置文件中解放出来.
拿一个最普通的 web 项目举例. 我们需要使用 servlet 容器, SpringBoot 就提供了嵌入式的 Tomcat 作为默认容器, 不需要一行配置就能直接以最普通的 Java 程序的方式启动: java -jar; 接收请求需要一个网络端口, 默认配置好 8080; 处理请求需要 servlet 的多线程特性, 默认配置好了最大线程数为 200; 处理好的请求以 Restful 风格返回给调用方, SpringBoot 默认配置好了 jackson 进行 JSON 序列化, 业务代码需要做的只是返回一个 POJO 对象; 连接池直接就默认配置了性能最好的的 Hikari, 以及连接池的默认尺寸为 10...... 在一个简单的 Web 应用中, 这些配置我们甚至都可能不了解或者没有意识到它们的存在, 就可以让程序正常运行.
这就是自动配置的魔力 -- 润物细无声.
那么自动配置是怎么实现的呢? 本文就从 POM 文件和 @SpringBootApplication 注解来简单分析一下自动配置原理.
真的只是简单地, 分析一下.
POM 文件
环境
SpringBoot 2.0.6
父项目
在每一个 SpringBoot 项目一开始的 POM 文件中, 就有一个父依赖:
- <parent>
- <groupId>org.springframework.boot</groupId>
- <artifactId>spring-boot-starter-parent</artifactId>
- <version>2.0.6.RELEASE</version>
- <relativePath/> <!-- lookup parent from repository -->
- </parent>
点进 artifactId 之后来到 spring-boot-starter-parent-2.0.6.RELEASE.pom 文件, 这个文件还有一个父依赖:
- <parent>
- <groupId>org.springframework.boot</groupId>
- <artifactId>spring-boot-dependencies</artifactId>
- <version>2.0.6.RELEASE</version>
- <relativePath>../../spring-boot-dependencies</relativePath>
- </parent>
再继续点进去来到 spring-boot-dependencies-2.0.6.RELEASE.pom 文件中. 在该文件的 <properties> 标签中可以看到各种各样的组件的版本信息, <dependencyManagement> 标签中声明了各个组件的 maven 坐标信息. 其中, 我数了一下, 在 SpringBoot 2.0.6 中一个有 177 个带有版本信息的组件名, 包括了大家熟悉的 Elasticsearch,activemq,Redis,kafka 等等.
这里 (spring-boot-dependencies-2.0.6.RELEASE.pom 文件) 称为 SpringBoot 的 "版本仲裁中心", 它是用来管理 SpringBoot 应用里面的所有依赖版本的地方. 它包含了大部分开发中会用到的一些组件的版本, 所以我们导入依赖默认是不需要写版本号的, SpringBoot 会自动帮我们配置需要的版本. 这样在引入某个组件的时候不用考虑这个组件和系统中已有的组件兼不兼容之类的问题, 避免了烦人的版本冲突问题.(当然, 没有在 dependencies 里面管理的依赖自然需要声明版本号)
启动器(Starters)
父项目做版本仲裁, 那么真正的 jar 包是从哪里导入进来的呢? 这就要说到我们的 starters 了. 点开 Web-starter 可以看到它帮我们导入了 Web 模块正常运行所依赖的组件, 就不用我们一个一个手动导入了.
所以, 所谓的 Starters 就是一系列依赖描述的组合, 我们可以通过导入这些 starters 就会有相应的依赖了并可以基于他们进行相应的开发
Springboot 把开发中中会遇到的场景都抽象成一个个的 starter, 比如(), 只需要在项目里面引入这些 starter 相关场景的所有依赖都会导入进来. 要用什么功能就导入什么场景的启动器
@SpringBootApplication
一个典型的 springboot 项目的入口类如下所示:
- @SpringBootApplication
- public class DemoApplication {
- public static void main(String[] args) {
- SpringApplication.run(DemoApplication.class, args);
- }
- }
只要运行 main 方法就能启动该应用. main 中运行 run 方法时需要传入一个类, 这个类正是使用 @SpringBootApplication 注解标注的类, 如果没有这个注解程序是跑不起来的.
这个注解标注在某个类上就说明这个类是 springboot 的主配置类, springboot 就应该运行这个类的 main 方法来启动 springboot 应用
点开这个注解的源码, 可以看到这是一个组合注解, 最主要的是这两个注解:
- @SpringBootConfiguration
- @EnableAutoConfiguration
@SpringBootConfiguration 标注在某个类上, 表示这是一个 SpringBoot 的配置类, 它的底层是 @Configuration, 属于 spring 的底层注解, 标注了这个注解的类表名这个类是一个配置类, 取代以前开发中的 xml 文件配置, 同时也表明这个类是 spring 容器中的组件, 受容器管理.
接下来是 @EnableAutoConfiguration 注解, 它的用处是开启自动配置, 使用 spring 开发需要手动配置的东西, 现在由 springboot 帮我们配置了, 具体的实现就是通过这个注解来实现的. 该组合注解有两个.
1. @AutoConfigurationPackage
它的 注解中的核心代码是 @Import({Registrar.class}).
@Import 的作用就是为容器中导入一个它指定的组件.
在 Registrar 这个类中有一个方法叫 registerBeanDefinitions, 用于注册一些 bean 定义信息:
- public void registerBeanDefinitions(AnnotationMetadata metadata, BeanDefinitionRegistry registry) {
- AutoConfigurationPackages.register(registry, (new AutoConfigurationPackages.PackageImport(metadata)).getPackageName());
- }
打个断点在这一行代码上, 运行
(new AutoConfigurationPackages.PackageImport(metadata)).getPackageName()
得到的结果是主配置类所在的包名, 目的就是将主配置类所在包及下面所有子包里面的所有组件扫描到 Spring 容器中. 同时也说明了, 如果在主配置所在包的上层包添加组件的话是不会被扫描到的, 不起作用的.
2. @Import({AutoConfigurationImportSelector.class})
该注解导入了一个自动配置的选择器, 真正地给容器中导入 springboot 自动帮我们配置好的配置类. 在 AutoConfigurationImportSelector 这个选择器中的 getAutoConfigurationEntry 方法中, 以全限定类名的方式把所有需要的配置类导入 springboot 容器中. 这些全限定类型所在文件路径为:
org/springframework/boot/spring-boot-autoconfigure/2.1.8.RELEASE/spring-boot-autoconfigure-2.1.8.RELEASE.jar!/META-INF/spring.factories
上述两个注解一个负责扫描我们将要加容器中的类, 一个加入 springboot 为我们自动配置好的类, springboot 通过这两种方式省略了我们大量的配置工作.
总结
本文从用于 maven 项目管理的 pom.xml 文件和标注在启动类上的 @SpringBootApplication 注解, 简单分析了 springboot 自动配置的实现. 前者通过版本仲裁中心为我们维护项目组件的版本, 防止依赖冲突; 后者通过在加载程序的时候导入数以百计的自动配置类实现自动配置.
原文发表于: https://pengcheng.site/2019/10/28/springboot-zi-dong-pei-zhi-qian-xi/
来源: https://www.cnblogs.com/mooba/p/11878586.html