Spring boot

一、Spring框架的起源

Spring 框架诞生于“黑暗”的 EJB 1 的时代（EJB 简单来说就是把已经编写好的程序/类打包放在服务器上执行），那是一个 J2EE 规范统治的时代，基于各种容器和 J2EE 规范的软件解决方案是唯一的“正道”，沉重的研发模式和生态让那个时代的开发者痛苦不堪。

 

随着经典巨著《Expert One-on-One J2EE Design and Development》的诞生，重规范时代终于迎来了一线曙光，该书的作者 Rod Johnson 在书中阐述了轻量级框架的研发理念，对原有笨重的规范进行了抨击，并基于书中的理念推出了最初版的 Spring 框架，并延续至今已达 10 多年之久。

 

Spring 框架是构建高效 Java 研发体系的一种最佳实践，它通过一系列统一而简洁的设计，为广大 Java 开发者开拓了一条光明的 Java 应用最佳实践之路。

 

大家熟知的 Spring IoC 与 AOP 自不必说，Spring 更是对 Java 应用开发中常用的技术进行了合理的设计和封装，使得 Java 应用开发者可以避免昔日因 API 和系统设计不当而易犯的错误，又能够高效地完成相应问题领域的研发工作，真可说是 Java 开发必备良器！

 

二、Spring IoC介绍

有部分 Java 开发者对 IoC（Inversion Of Control）和 DI（Dependency Injection）的概念有些混淆，认为二者是对等的。

 

IoC 其实有两种方式，一种就是 DI，而另一种是 DL，即 Dependency Lookup（依赖查找），前者是当前软件实体被动接受其依赖的其他组件被 IoC 容器注入，而后者则是当前软件实体主动去某个服务注册地查找其依赖的那些服务，概念之间的关系如图 1 所示可能更贴切些。

5-1ZI110520B60.png

我们通常提到的 Spring IoC，实际上是指 Spring 框架提供的 IoC 容器实现（IoC Container），而使用 Spring IoC 容器的一个典型代码片段就是：

任何一个使用 Spring 框架构建的独立的 Java 应用（Standalone Java Application），通常都会存在一行类似于“context.getBean（..）；”的代码。

 

实际上，这行代码做的就是 DL 的工作，而构建的任何一种 IoC 容器背后（比如 BeanFactory 或者 ApplicationContext）发生的事情，则更多是 DI 的过程（也可能有部分 DL 的逻辑用于对接遗留系统）。

 

Spring 的 IoC 容器中发生的事情其实也很简单，总结下来即两个阶段：

  • 采摘和收集“咖啡豆”（bean）
  • 研磨和烹饪咖啡

 

Spring IoC 容器的依赖注入工作可以分为两个阶段：

1）收集和注册

第一个阶段可以认为是构建和收集 bean 定义的阶段，在这个阶段中，我们可以通过 XML 或者 Java 代码的方式定义一些 bean，然后通过手动组装或者让容器基于某些机制自动扫描的形式，将这些 bean 定义收集到 IoC 容器中。

 

假设我们以 XML 配置的形式来收集并注册单一 bean，一般形式如下：

<bean id="mockService" class="..MockServiceImpl"> ...</bean>

如果嫌逐个收集 bean 定义麻烦，想批量地收集并注册到 IoC 容器中，我们也可以通过 XML Schema 形式的配置进行批量扫描并采集和注册：

<context:component-scan base-package="com.keevol">

注意基于 JavaConfig 形式的收集和注册，不管是单一还是批量，后面我们都会单独提及。

2）分析和组装

当第一阶段工作完成后，我们可以先暂且认为 IoC 容器中充斥着一个个独立的 bean，它们之间没有任何关系。

 

但实际上，它们之间是有依赖关系的，所以，IoC 容器在第二阶段要干的事情就是分析这些已经在 IoC 容器之中的 bean，然后根据它们之间的依赖关系先后组装它们。

 

如果 IoC 容器发现某个 bean 依赖另一个 bean，它就会将这另一个 bean 注入给依赖它的那个 bean，直到所有 bean 的依赖都注入完成，所有 bean 都“整装待发”，整个 IoC 容器的工作即算完成。

 

至于分析和组装的依据，Spring 框架最早是通过 XML 配置文件的形式来描述 bean 与 bean 之间的关系的，随着 Java 业界研发技术和理念的转变，基于 Java 代码和 Annotation 元信息的描述方式也日渐兴盛（比如 @Autowired 和 @Inject），但不管使用哪种方式，都只是为了简化绑定逻辑描述的各种“表象”，最终都是为本阶段的最终目的服务。

 

很多 Java 开发者一定认为 Spring 的 XML 配置文件是一种配置（Configuration），但本质上，这些配置文件更应该是一种代码形式，XML 在这里其实可以看作一种 DSL，它用来表述的是 bean 与 bean 之间的依赖绑定关系，如果没有 IoC 容器就要自己写代码新建（new）对象并配置（set）依赖。

 

三、Spring JavaConfig和常见Annotation

 

Java 5 的推出，加上当年基于纯 Java Annotation 的依赖注入框架 Guice 的出现，使得 Spring 框架及其社区也“顺应民意”，推出并持续完善了基于 Java 代码和 Annotation 元信息的依赖关系绑定描述方式，即 JavaConfig 项目。

 

基于 JavaConfig 方式的依赖关系绑定描述基本上映射了最早的基于 XML 的配置方式，比如：

1）表达形式层面

基于 XML 的配置方式是这样的：

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xmlns:context="http://www.springframework.org/schema/context"

    xsi:schemaLocation="http://www.springframework.org/schema/beans

        http://www.springframework.org/schema/beans/spring-beans.xsd

        http://www.springframework.org/schema/context

        http://www.springframework.org/schema/context/spring-context.xsd">

   

    <!-- bean定义 -->

</beans>

而基于 JavaConfig 的配置方式是这样的：

@Configuration

public class MockConfiguration{

    // bean定义

} 

任何一个标注了 @Configuration 的 Java 类定义都是一个 JavaConfig 配置类。

2）注册 bean 定义层面

基于 XML 的配置形式是这样的：

<bean id="mockService" class="..MockServiceImpl"> ...</bean>

而基于 JavaConfig 的配置形式是这样的：

  1. @Configuration
  2. public class MockConfiguration {
  3.     @Bean
  4.     public MockService mockService() {
  5.         return new MockServiceImpl();
  6.     }
  7. }

任何一个标注了 @Bean 的方法，其返回值将作为一个 bean 定义注册到 Spring 的 IoC 容器，方法名将默认成为该 bean 定义的 id。

3）表达依赖注入关系层面

为了表达 bean 与 bean 之间的依赖关系，在 XML 形式中一般是这样的：

  1. <bean id="mockService" class="..MockServiceImpl">
  2.     <property name="dependencyService" ref="dependencyService" />
  3. </bean>
  4. <bean id="dependencyService" class="DependencyServiceImpl" /> 

而在 JavaConfig 中则是这样的：

  1. @Configuration
  2. public class MockConfiguration {
  3.     @Bean
  4.     public MockService mockService() {
  5.         return new MockServiceImpl(dependencyService());
  6.     }
  8.     @Bean
  9.     public DependencyService dependencyService() {
  10.         return new DependencyServiceImpl();
  11.     }
  12. }

如果一个 bean 的定义依赖其他 bean，则直接调用对应 JavaConfig 类中依赖 bean 的创建方法就可以了。

 

在 JavaConfig 形式的依赖注入过程中，我们使用方法调用的形式注入依赖，如果这个方法返回的对象实例只被一个 bean 依赖注入，那也还好，如果多于一个 bean 需要依赖这个方法调用返回的对象实例，那是不是意味着我们就会创建多个同一类型的对象实例？

 

从代码表述的逻辑来看，直觉上应该是会创建多个同一类型的对象实例，但实际上最终结果却不是这样，依赖注入的都是同一个 Singleton 的对象实例，那这是如何做到的？

 

笔者一开始以为 Spring 框架会通过解析 JavaConfig 的代码结构，然后通过解析器转换加上反射等方式完成这一目的，但实际上 Spring 框架的设计和实现者采用了另一种更通用的方式，这在 Spring 的参考文档中有说明。即通过拦截配置类的方法调用来避免多次初始化同一类型对象的问题，一旦拥有拦截逻辑的子类发现当前方法没有对应的类型实例时才会去请求父类的同一方法来初始化对象实例，否则直接返回之前的对象实例。

 

所以，原来 Spring IoC 容器中有的特性（features）在 JavaConfig 中都可以表述，只是换了一种形式而已，而且，通过声明相应的 Java Annotation 反而“内聚”一处，变得更加简洁明了了。

那些高曝光率的 Annotation

至于 @Configuration，我想前面已经提及过了，这里不再赘述，下面我们看几个其他比较常见的 Annotation，便于为后面更好地理解 SpringBoot 框架的奥秘做准备。

1. @ComponentScan

@ComponentScan 对应 XML 配置形式中的 <context：component-scan> 元素，用于配合一些元信息 Java Annotation，比如 @Component 和 @Repository 等，将标注了这些元信息 Annotation 的 bean 定义类批量采集到 Spring 的 IoC 容器中。

 

我们可以通过 basePackages 等属性来细粒度地定制 @ComponentScan 自动扫描的范围，如果不指定，则默认 Spring 框架实现会从声明 @ComponentScan 所在类的 package 进行扫描。

 

@ComponentScan 是 SpringBoot 框架魔法得以实现的一个关键组件，大家可以重点关注，我们后面还会遇到它。

2. @PropertySource 与 @PropertySources

@PropertySource 用于从某些地方加载 *.properties 文件内容，并将其中的属性加载到 IoC 容器中，便于填充一些 bean 定义属性的占位符（placeholder），当然，这需要 PropertySourcesPlaceholderConfigurer 的配合。

 

如果我们使用 Java 8 或者更高版本开发，那么，我们可以并行声明多个 @PropertySource：

  1. @Configuration
  2. @PropertySource("classpath:1.properties")
  3. @PropertySource("classpath:2.properties")
  4. @PropertySource("...")
  5. public class XConfiguration{
  6.     ...
  7. }

如果我们使用低于 Java 8 版本的 Java 开发 Spring 应用，又想声明多个 @PropertySource，则需要借助 @PropertySources 的帮助了，代码如下所示：

纯文本复制

  1. @PropertySources({ @PropertySource("classpath:1.properties"), @PropertySource("classpath:2.properties"), ...})
  2. public class XConfiguration{
  3.     ...
  4. }

3. @Import 与 @ImportResource

在 XML 形式的配置中，我们通过 <import resource="XXX.xml"/> 的形式将多个分开的容器配置合到一个配置中，在 JavaConfig 形式的配置中，我们则使用 @Import 这个 Annotation 完成同样目的：

  1. @Configuration
  2. @Import(MockConfiguration.class)
  3. public class XConfiguration {
  4.     ...
  5. }

@Import 只负责引入 JavaConfig 形式定义的 IoC 容器配置，如果有一些遗留的配置或者遗留系统需要以 XML 形式来配置（比如 dubbo 框架），我们依然可以通过 @ImportResource 将它们一起合并到当前 JavaConfig 配置的容器中。任何一个标注了 @Configuration 的 Java 类定义都是一个 JavaConfig 配置类。

2）注册 bean 定义层面

基于 XML 的配置形式是这样的：

<bean id="mockService" class="..MockServiceImpl"> ...</bean>

而基于 JavaConfig 的配置形式是这样的：

  1. @Configuration
  2. public class MockConfiguration {
  3.     @Bean
  4.     public MockService mockService() {
  5.         return new MockServiceImpl();
  6.     }
  7. }

任何一个标注了 @Bean 的方法，其返回值将作为一个 bean 定义注册到 Spring 的 IoC 容器，方法名将默认成为该 bean 定义的 id。

3）表达依赖注入关系层面

为了表达 bean 与 bean 之间的依赖关系，在 XML 形式中一般是这样的：

  1. <bean id="mockService" class="..MockServiceImpl">
  2.     <property name="dependencyService" ref="dependencyService" />
  3. </bean>
  4. <bean id="dependencyService" class="DependencyServiceImpl" /> 

而在 JavaConfig 中则是这样的：

  1. @Configuration
  2. public class MockConfiguration {
  3.     @Bean
  4.     public MockService mockService() {
  5.         return new MockServiceImpl(dependencyService());
  6.     }
  8.     @Bean
  9.     public DependencyService dependencyService() {
  10.         return new DependencyServiceImpl();
  11.     }
  12. }

如果一个 bean 的定义依赖其他 bean，则直接调用对应 JavaConfig 类中依赖 bean 的创建方法就可以了。

 

在 JavaConfig 形式的依赖注入过程中，我们使用方法调用的形式注入依赖，如果这个方法返回的对象实例只被一个 bean 依赖注入，那也还好，如果多于一个 bean 需要依赖这个方法调用返回的对象实例，那是不是意味着我们就会创建多个同一类型的对象实例？

 

从代码表述的逻辑来看，直觉上应该是会创建多个同一类型的对象实例，但实际上最终结果却不是这样，依赖注入的都是同一个 Singleton 的对象实例，那这是如何做到的？

 

笔者一开始以为 Spring 框架会通过解析 JavaConfig 的代码结构，然后通过解析器转换加上反射等方式完成这一目的，但实际上 Spring 框架的设计和实现者采用了另一种更通用的方式，这在 Spring 的参考文档中有说明。即通过拦截配置类的方法调用来避免多次初始化同一类型对象的问题，一旦拥有拦截逻辑的子类发现当前方法没有对应的类型实例时才会去请求父类的同一方法来初始化对象实例，否则直接返回之前的对象实例。

 

所以，原来 Spring IoC 容器中有的特性（features）在 JavaConfig 中都可以表述，只是换了一种形式而已，而且，通过声明相应的 Java Annotation 反而“内聚”一处，变得更加简洁明了了。

那些高曝光率的 Annotation

至于 @Configuration，我想前面已经提及过了，这里不再赘述，下面我们看几个其他比较常见的 Annotation，便于为后面更好地理解 SpringBoot 框架的奥秘做准备。

1. @ComponentScan

@ComponentScan 对应 XML 配置形式中的 <context：component-scan> 元素，用于配合一些元信息 Java Annotation，比如 @Component 和 @Repository 等，将标注了这些元信息 Annotation 的 bean 定义类批量采集到 Spring 的 IoC 容器中。

 

我们可以通过 basePackages 等属性来细粒度地定制 @ComponentScan 自动扫描的范围，如果不指定，则默认 Spring 框架实现会从声明 @ComponentScan 所在类的 package 进行扫描。

 

@ComponentScan 是 SpringBoot 框架魔法得以实现的一个关键组件，大家可以重点关注，我们后面还会遇到它。

2. @PropertySource 与 @PropertySources

@PropertySource 用于从某些地方加载 *.properties 文件内容，并将其中的属性加载到 IoC 容器中，便于填充一些 bean 定义属性的占位符（placeholder），当然，这需要 PropertySourcesPlaceholderConfigurer 的配合。

 

如果我们使用 Java 8 或者更高版本开发，那么，我们可以并行声明多个 @PropertySource：

  1. @Configuration
  2. @PropertySource("classpath:1.properties")
  3. @PropertySource("classpath:2.properties")
  4. @PropertySource("...")
  5. public class XConfiguration{
  6.     ...
  7. }

如果我们使用低于 Java 8 版本的 Java 开发 Spring 应用，又想声明多个 @PropertySource，则需要借助 @PropertySources 的帮助了，代码如下所示：

纯文本复制

  1. @PropertySources({ @PropertySource("classpath:1.properties"), @PropertySource("classpath:2.properties"), ...})
  2. public class XConfiguration{
  3.     ...
  4. }

3. @Import 与 @ImportResource

在 XML 形式的配置中，我们通过 <import resource="XXX.xml"/> 的形式将多个分开的容器配置合到一个配置中，在 JavaConfig 形式的配置中，我们则使用 @Import 这个 Annotation 完成同样目的：

  1. @Configuration
  2. @Import(MockConfiguration.class)
  3. public class XConfiguration {
  4.     ...
  5. }

@Import 只负责引入 JavaConfig 形式定义的 IoC 容器配置，如果有一些遗留的配置或者遗留系统需要以 XML 形式来配置（比如 dubbo 框架），我们依然可以通过 @ImportResource 将它们一起合并到当前 JavaConfig 配置的容器中。

随着动态语言的流行（Ruby、Groovy、Scala、Node.js），Java 的开发显得格外的笨重，繁多的配置、低下的开发效率、复杂的部署流程以及第三方技术集成难度大。

 

在上述环境下，Spring Boot 应运而生。它使用“习惯优于配置”（项目中存在大量的配置，此外还内置一个习惯性的配置，让你无须手动进行配置）的理念让你的项目快速运行起来。

 

使用 Spring Boot 很容易创建一个独立运行（运行 jar，内嵌 Servlet 容器）、准生产级别的基于 Spring 框架的项目，使用 Spring Boot 你可以不用或者只需要很少的 Spring 配置。

Spring Boot 核心功能

1）独立运行的 Spring 项目

Spring Boot 可以以 jar 包的形式独立运行，运行一个 Spring Boot 项目只需通过 java–jar xx.jar 来运行。

2）内嵌 Servlet 容器

Spring Boot 可选择内嵌 Tomcat、Jetty 或者 Undertow，这样我们无须以 war 包形式部署项目。

3）提供 starter 简化 Maven 配置

Spring 提供了一系列的 starter pom 来简化 Maven 的依赖加载，例如，当你使用了spring-boot-starter-web 时，会自动加入如图 1 所示的依赖包。

4）自动配置 Spring

Spring Boot 会根据在类路径中的 jar 包、类，为 jar 包里的类自动配置 Bean，这样会极大地减少我们要使用的配置。当然，Spring Boot 只是考虑了大多数的开发场景，并不是所有的场景，若在实际开发中我们需要自动配置 Bean，而 Spring Boot 没有提供支持，则可以自定义自动配置。

5）准生产的应用监控

Spring Boot 提供基于 http、ssh、telnet 对运行时的项目进行监控。

6）无代码生成和 xml 配置

Spring Boot 的神奇的不是借助于代码生成来实现的，而是通过条件注解来实现的，这是 Spring 4.x 提供的新特性。Spring 4.x 提倡使用 Java 配置和注解配置组合，而 Spring Boot 不需要任何 xml 配置即可实现 Spring 的所有配置。

Spring Boot的优缺点

1）优点

  • 快速构建项目。
  • 对主流开发框架的无配置集成。
  • 项目可独立运行，无须外部依赖Servlet容器。
  • 提供运行时的应用监控。
  • 极大地提高了开发、部署效率。
  • 与云计算的天然集成。

2）缺点

  • 版本迭代速度很快，一些模块改动很大。
  • 由于不用自己做配置，报错时很难定位。
  • 网上现成的解决方案比较少。

 

四、SpringBoot快速搭建

 

1）打开浏览器，输入网址 http://start.spring.io/ ，如图 1 所示：

5-1ZI1162941D6.png

2）创建一个最简单的依赖 Web 模块的 SpringBoot 应用，填写项目信息，如图 1 所示。

我们在此以 Maven 作为项目构建方式，Spring Boot 还支持以 Gradle 作为项目构建工具。部署形式以 jar 包形式，当然也可以用传统的 war 包形式。Spring Boot 选择2.1.6，Spring boot 还支持以 Groovy 语言开发，应用中选择 Java 作为开发语言。

 

3）选择完之后，下载代码，如图 2 所示：

5-1ZI116363Y28.png

一般情况下，我们会得到一个 SpringBoot 应用的启动类，如下面代码所示：

  1. import org.springframework.boot.SpringApplication;
  2. import org.springframework.boot.autoconfigure.SpringBootApplication;
  4. @SpringBootApplication
  5. public class DemoApplication {
  6.     public static void main(String[] args) {
  7.         SpringApplication.run(DemoApplication.class, args);
  8.     }
  9. }

 

所有的 SpringBoot 无论怎么定制，本质上与上面的启动类代码是一样的，而以上代码示例中，Annotation 定义（@SpringBootApplication）和类定义（SpringApplication.run）最为耀眼，那么，要揭开 SpringBoot 应用的奥秘，很明显的，我们只要先从这两位开始就可以了。

五、SpringBoot中@SpringBootApplication注解的三体结构解析

@SpringBootApplication 是一个“三体”结构，实际上它是一个复合 Annotation：

@Target(ElementType.TYPE)

@Retention(RetentionPolicy.RUNTIME)

@Documented

@Inherited

@Configuration

@EnableAutoConfiguration

@ComponentScanpublic

@interface

SpringBootApplication{...}

虽然它的定义使用了多个 Annotation 进行元信息标注，但实际上对于 SpringBoot 应用来说，重要的只有三个 Annotation，而“三体”结构实际上指的就是这三个 Annotation：

  • @Configuration
  • @EnableAutoConfiguration
  • @ComponentScan

 

所以，如果我们使用如下的 SpringBoot 启动类，整个 SpringBoot 应用依然可以与之前的启动类功能对等：

  1. @Configuration
  2. @EnableAutoConfiguration
  3. @ComponentScanpublic
  4. class DemoApplication {
  5.     public static void main(String[] args) {
  6.         SpringApplication.run(DemoApplication.class, args);
  7.     }
  8. }

但每次都写三个 Annotation 显然过于繁琐，所以写一个 @SpringBootApplication 这样的一站式复合 Annotation 显然更方便些。

@Configuration 创世纪

这里的 @Configuration 对我们来说并不陌生，它就是 JavaConfig 形式的 Spring IoC 容器的配置类使用的那个 @Configuration，既然 SpringBoot 应用骨子里就是一个 Spring 应用，那么，自然也需要加载某个 IoC 容器的配置，而 SpringBoot 社区推荐使用基于 JavaConfig 的配置形式，所以，很明显，这里的启动类标注了 @Configuration 之后，本身其实也是一个 IoC 容器的配置类！

 

很多 SpringBoot 的代码示例都喜欢在启动类上直接标注 @Configuration 或者 @SpringBootApplication，对于初接触 SpringBoot 的开发者来说，其实这种做法不便于理解，如果我们将上面的 SpringBoot 启动类拆分为两个独立的 Java 类，整个形势就明朗了：

@Configuration

@EnableAutoConfiguration

@ComponentScan

public class DemoConfiguration {

    @Bean

    public Controller controller() {

        return new Controller();

    }

}

 

public class DemoApplication {

    public static void main(String[] args) {

        SpringApplication.run(DemoConfiguration.class, args);

    }

}

所以，启动类 DemoApplication 其实就是一个标准的 Standalone 类型 Java 程序的 main 函数启动类，没有什么特殊的。而 @Configuration 标注的 DemoConfiguration 定义其实也是一个普通的 JavaConfig 形式的 IoC 容器配置类。

@EnableAutoConfiguration 的功效

@EnableAutoConfiguration 其实也没啥“创意”，各位是否还记得 Spring 框架提供的各种名字为 @Enable 开头的 Annotation 定义？

 

比如 @EnableScheduling、@EnableCaching、@EnableMBeanExport 等，@EnableAutoConfiguration 的理念和“做事方式”其实一脉相承，简单概括一下就是，借助 @Import 的支持，收集和注册特定场景相关的 bean 定义：

  • @EnableScheduling 是通过 @Import 将 Spring 调度框架相关的 bean 定义都加载到 IoC 容器。
  • @EnableMBeanExport 是通过 @Import 将 JMX 相关的 bean 定义加载到 IoC 容器。

 

而 @EnableAutoConfiguration 也是借助 @Import 的帮助，将所有符合自动配置条件的 bean 定义加载到 IoC 容器，仅此而已！

 

@EnableAutoConfiguration 作为一个复合 Annotation，其自身定义关键信息如下：

@Target(ElementType.TYPE)

@Retention(RetentionPolicy.RUNTIME)

@Documented

@Inherited

@AutoConfigurationPackage

@Import(EnableAutoConfigurationImportSelector.class)

public @interface EnableAutoConfiguration {...}

其中，最关键的要属 @Import（EnableAutoConfigurationImportSelector.class），借助 EnableAutoConfigurationImportSelector，@EnableAutoConfiguration 可以帮助 SpringBoot 应用将所有符合条件的 @Configuration 配置都加载到当前 SpringBoot 创建并使用的 IoC 容器，就跟一只“八爪鱼”一样（如图 1 所示）。

5-1ZI1093132I5.png

借助于 Spring 框架原有的一个工具类：SpringFactoriesLoader 的支持，@EnableAutoConfiguration 可以“智能”地自动配置功效才得以大功告成！

SpringFactoriesLoader详解

SpringFactoriesLoader 属于 Spring 框架私有的一种扩展方案（类似于 Java 的 SPI 方案 java.util.ServiceLoader），其主要功能就是从指定的配置文件 META-INF/spring.factories 加载配置，spring.factories 是一个典型的 java properties 文件，配置的格式为 Key=Value 形式，只不过 Key 和 Value 都是 Java 类型的完整类名（Fully qualified name），比如：

 

example.MyService=example.MyServiceImpl1,example.MyServiceImpl2 然后框架就可以根据某个类型作为 Key 来查找对应的类型名称列表了：

  1. public abstract class SpringFactoriesLoader {
  2.     // ...
  3.     public static <T> List<T> loadFactories(Class<T> factoryClass, ClassLoader classLoader) {
  4.         ...
  5.     }
  7.     public static List<String> loadFactoryNames(Class<?> factoryClass, ClassLoader classLoader) {
  8.         ...
  9.     }
  10.     // ...
  11. }

对于 @EnableAutoConfiguration 来说，SpringFactoriesLoader 的用途稍微不同一些，其本意是为了提供 SPI 扩展的场景，而在 @EnableAutoConfiguration 的场景中，它更多是提供了一种配置查找的功能支持，即根据 @EnableAutoConfiguration 的完整类名 org.springframework.boot.autoconfigure.EnableAutoConfiguration 作为查找的 Key，获取对应的一组 @Configuration 类：

org.springframework.boot.autoconfigure.EnableAutoConfiguration=

\org.springframework.boot.autoconfigure.admin.SpringApplicationAdmin- JmxAutoConfiguration,

\org.springframework.boot.autoconfigure.aop.AopAutoConfiguration,

\org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration,

\org.springframework.boot.autoconfigure.MessageSourceAutoConfiguration,

\org.springframework.boot.autoconfigure.PropertyPlaceholderAuto- Configuration,

\org.springframework.boot.autoconfigure.batch.BatchAutoConfiguration,

\org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration,

\org.springframework.boot.autoconfigure.cassandra.CassandraAuto-Configuration,

\org.springframework.boot.autoconfigure.cloud.CloudAutoConfiguration,

\org.springframework.boot.autoconfigure.context.ConfigurationProperties-AutoConfiguration,

\org.springframework.boot.autoconfigure.dao.PersistenceException-TranslationAutoConfiguration,

\org.springframework.boot.autoconfigure.data.cassandra.Cassandra-DataAutoConfiguration,

\org.springframework.boot.autoconfigure.data.cassandra.Cassandra-RepositoriesAutoConfiguration,

\...

以上是从 SpringBoot 的 autoconfigure 依赖包中的 META-INF/spring.factories 配置文件中摘录的一段内容，可以很好地说明问题。

 

所以，@EnableAutoConfiguration 自动配置的魔法其实就变成了：从 classpath 中搜寻所有 META-INF/spring.factories 配置文件，并将其中 org.spring-framework.boot.autoconfigure.EnableAutoConfiguration 对应的配置项通过反射（Java Reflection）实例化为对应的标注了 @Configuration 的 JavaConfig 形式的 IoC 容器配置类，然后汇总为一个并加载到 IoC 容器。

可有可无的@ComponentScan

为啥说 @ComponentScan 是可有可无的？

 

因为原则上来说，作为 Spring 框架里的“老一辈革命家”，@ComponentScan 的功能其实就是自动扫描并加载符合条件的组件或 bean 定义，最终将这些 bean 定义加载到容器中。加载 bean 定义到 Spring 的 IoC 容器，我们可以手工单个注册，不一定非要通过批量的自动扫描完成，所以说 @ComponentScan 是可有可无的。

 

对于 SpringBoot 应用来说，同样如此，比如我们本章的启动类：

  1. @Configuration
  2. @EnableAutoConfiguration
  3. @ComponentScanpublic
  4. class DemoApplication {
  5.     public static void main(String[] args) {
  6.         SpringApplication.run(DemoApplication.class, args);
  7.     }
  8. }

如果我们当前应用没有任何 bean 定义需要通过 @ComponentScan 加载到当前 SpringBoot 应用对应使用的 IoC 容器，那么，除去 @ComponentScan 的声明，当前 SpringBoot 应用依然可以照常运行，功能对等。

 

posted @ 2020-10-21 10:53  ZhangYunZhu  阅读(104)  评论(0)  编辑  收藏  举报