SpringBoot原理1. 2. 3. 3.3.3.2.3.2.3.3.4. 3.3.3.2.3.2.3.2.2.3.

1. 配置的优先级

配置文件优先级排名（从高到低）：

结论-优先级：命令行参数 > 系统属性参数 > properties参数 > yml参数 > yaml参数

注意事项：

2. 多环境配置

3. Spring IOC容器中Bean的管理

3.1 获取Bean

注意:声明一个bean对象如果没有指定名称,默认类名首字母小写

问题：输出的bean对象地址值是一样的，说明IOC容器当中的bean对象有几个？

那么我们应该怎样使用并定义第三方的bean呢？

注意事项：

@Component及衍生注解与@Bean注解使用场景？

术语："配置类"，英文Configuration Class：

SpringBoot原理篇，主要偏向于底层原理。

包括这么三个部分：

配置优先级：SpringBoot项目当中属性配置的常见方式以及不同配置的优先级
Spring IOC容器中Bean的管理
剖析SpringBoot的底层原理

1. 配置的优先级

如果我们通过多种方式配置了同一个属性，到底是哪种方式生效？

SpringBoot项目当中支持的三类配置文件：

application.properties
application.yaml
application.yml

在SpringBoot项目当中，我们要想配置一个属性，可以通过这三种方式当中的任意一种来配置都可以。

那么如果项目中同时存在这三种配置文件，且都配置了同一个属性，如：Tomcat端口号，到底哪一份配置文件生效呢？

application.properties

server.port=8081

application.yaml

server:
   port: 8082

application.yml

server:
   port: 8083

我们启动SpringBoot程序，测试下三个配置文件中哪个Tomcat端口号生效：

properties、yaml、yml三种配置文件同时存在

结论：properties、yaml、yml三种配置文件，优先级最高的是properties

yaml、yml两种配置文件同时存在

配置文件优先级排名（从高到低）：

properties配置文件

yml配置文件

yaml配置文件

注意事项：虽然SpringBoot支持多种格式配置文件，但是在项目开发时，推荐统一使用一种格式的配置。（yml是主流）

在SpringBoot项目当中除了以上3种配置文件外，SpringBoot为了增强程序的扩展性，除了支持配置文件的配置方式以外，还支持另外两种常见的配置方式：

1. Java系统属性配置 - VM options（格式： -D****key=value ）

-Dserver.port=9000

**2. 命令行参数 - Program arguments（格式：--**key=value ）

--server.port=10010

那在IDEA当中运行程序时，如何来指定Java系统属性和命令行参数呢？

在IDEA当中已经提供了可视化的配置界面！

编辑启动程序的配置信息

重启服务，同时配置Tomcat端口(三种配置文件、系统属性、命令行参数)，测试哪个Tomcat端口号生效：

结论-优先级：命令行参数 > 系统属性参数 > properties参数 > yml参数 > yaml参数

思考：如果项目已经打包上线了，这个时候我们又如何来设置Java系统属性和命令行参数呢？

java -Dserver.port=9000 -jar XXXXX.jar --server.port=10010

下面我们来演示下打包程序运行时指定Java系统属性和命令行参数：

执行maven打包指令package，把项目打成jar文件
使用命令：java -jar 方式运行jar文件程序

注意事项：

SpringBoot项目进行打包时，需要引入插件 spring-boot-maven-plugin (基于官网骨架创建项目，会自动添加该插件)

2. 多环境配置

在实际的项目开发中，一个项目通常会存在多个环境，例如：开发环境、测试环境和生产环境/线上环境等。不同环境的配置也不尽相同，例如开发环境使用的是开发数据库，测试环境使用的是测试数据库，而生产环境使用的是线上的正式数据库等。

在SpringBoot当中，它就给我们提供了多环境的配置方式，对于当前项目，我们可以定义多套环境对应的配置文件，比如：

开发环境，我可以定义一份配置文件叫application-dev.yml develop-开发
测试环境的配置文件 - application-test.yml test-测试
生成环境 - application-prod.yml production-生产

多环境配置文件的命名格式：

application-环境的标识.yml/properties/yaml

提问：此时我项目一启动，到底用哪套环境呢？

回答：SpringBoot在启动的时候，它所加载的配置文件或者说它所使用的配置文件无非是application.properties或者是application.yml/yaml，此时就需要在主配置文件application.yml当中来指定一个参数，来指定我们到底要使用哪套环境的配置文件

profiles：配置文件 active：有效的

3. Spring IOC容器中Bean的管理

复习：什么是Bean？

IOC容器当中所存储管理的对象就是Bean。

复习：我们可以通过Spring当中提供的注解@Component以及它的三个衍生注解（@Controller、@Service、@Repository）来声明IOC容器中的bean对象，同时我们也学习了如何为应用程序注入运行时所需要依赖的bean对象，也就是依赖注入DI。

我们今天主要学习IOC容器中Bean的其他使用细节，主要学习以下四方面：

如何从IOC容器中手动的获取到bean对象
bean的作用域配置
bean的生命周期相关的两个注解
如何管理第三方的bean对象

先来学习第一方面，从IOC容器中获取bean对象。

3.1 获取Bean

默认情况下，SpringBoot / Spring项目在启动的时候会自动的创建IOC容器(也称为Spring容器) ，并且在启动的过程当中会自动的将bean对象都创建好并且存放在IOC容器当中。
应用程序在运行时需要依赖什么bean对象，就直接进行依赖注入就可以了。

而在Spring容器中提供了一些方法，可以主动从IOC容器中获取到bean对象，下面介绍3种常用方式： 都是getBean()方法

手动调用Spring/IOC容器 - ApplicationContext当中的实例方法getBean()来获取到bean对象

1. 根据name获取bean / 根据bean的名称来获取bean

Object getBean(String name)

2. 根据bean的类型来获取bean

<T> T getBean(Class<T> requiredType)

3. 根据name获取bean（带类型转换） / 根据bean的名称以及类型来获取bean

<T> T getBean(String name, Class<T> requiredType)

思考：要从IOC容器当中来获取到bean对象，需要先拿到IOC容器对象，怎么样才能拿到IOC容器呢？

想获取到IOC容器，直接将IOC容器对象注入进来就可以了

注意:声明一个bean对象如果没有指定名称,默认类名首字母小写

测试方法：从IOC容器中获取bean对象

    @Autowired
    private ApplicationContext applicationContext; // IOC容器对象

    @Test
    public void testGetBean() {
        // 根据bean的名称获取
        DeptController bean1 = (DeptController) applicationContext.getBean("deptController");
        System.out.println(bean1);

        // 根据bean的类型获取
        DeptController bean2 = applicationContext.getBean(DeptController.class);
        System.out.println(bean2);

        // 根据bean的名称及类型获取
        DeptController bean3 = applicationContext.getBean("deptController", DeptController.class);
        System.out.println(bean3);
    }

运行测试方法后，看控制台输出：

问题：输出的bean对象地址值是一样的，说明IOC容器当中的bean对象有几个？

答案：只有一个。（默认情况下，IOC容器中的bean对象是单例）

那么能不能将bean对象设置为非单例的(每次获取的bean都是一个新对象)？

可以，在下一个知识点(bean作用域配置)中讲解。

注意事项：

上述所说的【Spring项目启动时，会把其中的bean都创建好】还会受到作用域及延迟初始化影响，这里主要针对于默认的单例非延迟加载的bean而言。

提问：既然SpringBoot启动类的run方法的返回值ConfigurableApplicationContext就是Spring / IOC容器对象，那为什么不直接在SpringBoot项目的启动类/引导类当中来获取bean呢？

单一职责原则，为了保持启动类代码的纯粹性！

补充：在根据bean的名称来获取bean对象时，如果故意把bean的名称首字母大写，那么运行后会报什么错？

NoSuchBeanDefinitionException： **表示在应用程序中没有找到指定的 Bean 定义 **Definition：定义

3.2 Bean作用域

IOC容器当中Bean的作用域

在前面我们提到的在Spring/IOC容器当中，默认bean对象是单例模式(只有一个实例对象) 。

那么如何设置bean对象为非单例呢？

需要设置bean的作用域。
我们所声明的bean对象到底是单例的还是多例的，其实是取决于bean的作用域的。
借助Spring中的@Scope注解来进行配置作用域

3.2.1 Bean的作用域的配置

在Spring当中所声明的Bean支持五种作用域，后三种在web环境才生效：

作用域	说明
singleton	代表在整个Spring容器当中/内，同名称的bean对象只有一个实例（单例）（默认）
prototype	每次使用该bean时会创建新的实例（非单例）
request	每个请求范围内会创建新的实例（web环境中，了解）
session	每个会话范围内会创建新的实例（web环境中，了解）
application	每个应用范围内会创建新的实例（web环境中，了解）

知道了bean的5种作用域了，我们要怎么去设置一个bean的作用域呢？

可以借助Spring中的@Scope注解来进行配置作用域

3.2.2 @Lazy注解

1). 测试一

控制器

//默认bean的作用域为：singleton (单例)
@Lazy //延迟加载/延迟初始化（第一次使用bean对象时，才会创建bean对象并交给ioc容器管理）
@RestController
@RequestMapping("/depts")
public class DeptController {

    @Autowired
    private DeptService deptService;

    public DeptController(){
        System.out.println("DeptController constructor ....");
    }

    //省略其他代码...
}

测试类

@SpringBootTest
class SpringbootWebConfig2ApplicationTests {

    @Autowired
    private ApplicationContext applicationContext; //IOC容器对象

    //bean的作用域
    @Test
    public void testScope(){
        for (int i = 0; i < 10; i++) {
            DeptController deptController = applicationContext.getBean(DeptController.class);
            System.out.println(deptController);
        }
    }
}

重启SpringBoot服务，运行测试方法，查看控制台打印的日志：

注意事项：

IOC容器中的bean默认使用的作用域：singleton (单例)
IOC容器中管理的bean默认都是singleton单例的！
默认singleton的bean，在容器启动时被创建，可以使用@Lazy注解来延迟初始化(延迟到第一次使用时)，类似于饿汉单例模式！

2). 测试二

修改控制器DeptController代码：

@Scope("prototype") //bean作用域为非单例
@Lazy //延迟加载/延迟初始化/懒加载（第一次使用bean对象时，才会创建bean对象并交给ioc容器管理）
@RestController
@RequestMapping("/depts")
public class DeptController {

    @Autowired
    private DeptService deptService;

    public DeptController(){
        System.out.println("DeptController constructor ....");
    }

    //省略其他代码...
}

重启SpringBoot服务，再次执行测试方法，查看控制台打印的日志：

注意事项：

prototype非单例的bean，每一次使用该bean的时候都会创建一个新的实例
实际开发当中，绝大部分的Bean是单例的，也就是说绝大部分Bean不需要配置scope属性，因为如果创建成非单例的bean，频繁的创建bean对象是非常消耗资源的，并且还会占用内存，增加JVM垃圾回收的负担！因此项目开发当中，所有的bean都是单例的。

3.3 Bean的生命周期相关的两个注解

@PostConstruct

作用：用来标识初始化的方法
Post：在...之后 Construct：构造函数
被@PostConstruct注解标识的方法是在构造函数运行之后运行的！
执行时机：{bean实例化之后，依赖注入完成后}， 也就是构造方法运行之后 ， 自动执行****该初始化的方法。
使用场景：执行一些初始化操作 / 逻辑，比如资源加载、缓存的初始化等。
方法要求： 不能有任何参数，注意：是自动执行的方法，而不是我们手动调用的方法 。该方法也不要被static修饰，就是一个普通方法。

@PreDestroy

Pre：在....之前 destroy：销毁
作用：销毁方法，用于标记在容器销毁bean实例之前执行的方法
执行时机：会在bean销毁之前自动执行，只执行一次。
使用场景：执行一些清理操作 / 逻辑，比如资源的释放、连接的关闭、清理数据等。
方法要求：不能有任何参数。

提问：什么时候IOC容器 / Spring容器会销毁bean的实例对象呢？

回答：服务器关闭的时候会自动销毁！

注意：

如果将当前bean的作用域设置成非单例的，也就意味着这个bean对象会创建多个，那么Spring容器将bean对象创建完成之后，Spring容器就已经没有管理该Bean对象了，Spring容器只负责把bean对象创建出来，至于bean对象什么时候销毁就不受Spring的控制了，受垃圾回收的控制，受JVM的控制！

代码：

// Bean的生命周期的两个方法,方法要求不能有任何参数,否则运行会报错
    
    /**
     * 在bean实例化之后,依赖注入完成之后自动执行该初始化操作
     */
    @PostConstruct // 该注解标识的方法,会在构造函数运行之后 自动执行。
    public void init() {
        System.out.println("DeptController init...");
    }

    /**
     * 在bean对象销毁之前自动执行一些清理操作
     */
    @PreDestroy // 该注解标识的方法会在bean对象销毁之前自动执行,只执行一次
    public void destroy() {
        System.out.println("DeptController destroy...");
    }

如果该方法里面有参数，看看运行后会报什么错？

被@PostConstruct或者@PerDestroy注解标识的生命周期的方法需要一个无参数的方法！

3.4 关于第三方bean的声明

之前我们所配置的bean，像controller、service，dao三层体系下编写的类，这些类都是我们在项目当中自己定义的类(自定义类)。当我们要声明这些bean，也非常简单，我们只需要在类上加上@Component以及它的这三个衍生注解（ @Controller、@Service、@Repository），就可以来声明这个bean对象了。
但是在我们项目开发当中，还有一种情况就是这个类它不是我们自己编写的，而是我们引入的第三方依赖当中提供的。

在pom.xml文件中，引入dom4j：

<!--Dom4j-->
<dependency>
    <groupId>org.dom4j</groupId>
    <artifactId>dom4j</artifactId>
    <version>2.1.3</version>
</dependency>

dom4j就是第三方组织提供的，dom4j中的SAXReader类就是第三方编写的。

当我们需要使用到SAXReader对象时，直接进行依赖注入是不是就可以了呢？

按照我们之前的做法，需要在SAXReader类上添加一个注解@Component（将当前类交给IOC容器管理）

结论：第三方提供的类是只读的。无法在第三方类上添加@Component注解或衍生注解。

那么我们应该怎样使用并定义第三方的bean呢？

如果要管理的bean对象来自于第三方（不是自定义的），是无法用@Component 及衍生注解声明bean的，因为没办法修改源码，此时就需要用到@Bean注解。

解决方案1：在启动类 / 引导类上添加@Bean标识的方法

@Bean注解的标识的方法，会将当前方法的返回值对象交给Spring的IOC容器管理，成为IOC容器当中的bean对象，并且该方法在项目启动时会自动调用。
Spring会自动调用在配置类当中使用了@Bean注解标识的方法，并将方法的返回值加载到Spring的IOC容器当中。

@SpringBootApplication
public class SpringbootWebConfig2Application {

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

    //声明第三方bean
    @Bean //将当前方法的返回值对象交给IOC容器管理, 成为IOC容器当中的bean,并且该方法在项目启动时会自动调用
    public SAXReader saxReader(){
        return new SAXReader();
    }
}

说明：以上在启动类中声明第三方Bean的作法，不建议 / 推荐使用（项目中要保证启动类的纯粹性 => 单一职责原则）

解决方案2：单独定义一个配置类，在配置类中定义@Bean标识的方法

如果需要定义第三方Bean时，通常会单独定义一个配置类

package com.gch.config;

import org.dom4j.io.SAXReader;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * 在配置类当中对第三方bean进行集中的配置管理
 */
@Configuration // 该注解标识当前类是Spring当中的配置类,@Configuration注解的底层是@Component注解
public class CommonConfig {
    /**
     * 声明第三方Bean
     * @Bean注解的作用:将当前方法的返回值对象交给IOC容器管理,成为IOC容器当中的Bean,并且该方法在项目启动时会自动调用
     * 通过@Bean注解的name/value属性来指定Bean的名称,如果未指定,默认是方法名
     * @return
     */
    @Bean
    public SAXReader saxReader(){
        return new SAXReader();
    }
}

在方法上加上一个@Bean注解，Spring 容器在启动的时候，它会自动的调用这个方法，并将方法的返回值声明为Spring容器当中的Bean对象。

注意事项：

通过@Bean注解的name或value属性可以声明bean的名称，如果不指定，默认bean的名称就是方法名。
如果第三方bean需要依赖其它bean对象，直接在bean定义方法中设置形参即可，容器会根据类型自动装配。

@Component及衍生注解与@Bean注解使用场景？

关于Bean大家只需要保持一个原则：

如果是在项目当中我们自己定义的类，想将这些类交给IOC容器管理，我们直接使用@Component以及它的衍生注解来声明就可以。
如果这个类它不是我们自己定义的，而是引入的第三方依赖当中提供的类，而且我们还想将这个类交给IOC容器管理。此时我们就需要单独定义一个配置类(@Configuration)，在配置类当中来定义一个方法，在方法上加上一个@Bean注解，通过这种方式来声明第三方的bean对象。

4. SpringBoot原理

基于SpringBoot进行Web程序的开发是非常简单、非常高效的。

SpringBoot使我们能够集中精力地去关注业务功能的开发，而不用过多地关注框架本身的配置使用。

而我们前面所学习的都是面向应用层面的技术，接下来我们开始学习SpringBoot的原理，这部分内容偏向于底层的原理分析。

回顾一下Spring家族的框架：

Spring是目前世界上最流行的Java框架，它可以帮助我们更加快速、更加容易的来构建Java项目。而在Spring家族当中提供了很多优秀的框架，而所有的框架都是基于一个基础框架的SpringFramework(也就是Spring框架) 。而前面我们也提到，如果我们直接基于Spring框架进行项目的开发，会比较繁琐。

这个繁琐主要体现在两个地方：

aa在pom.xml中依赖配置比较繁琐，在项目开发时，需要自己去找到对应的依赖，还需要找到依赖它所配套的依赖以及对应版本，否则就会出现版本冲突问题。
在使用Spring框架进行项目开发时，需要在Spring的配置文件中做大量的配置，这就造成Spring框架入门难度较大，学习成本较高。

基于Spring存在的问题，官方在Spring框架4.0版本之后，又推出了一个全新的框架：SpringBoot。

通过 SpringBoot来简化Spring框架的开发(是简化不是替代) 。我们直接基于SpringBoot来构建Java项目，会让我们的项目开发更加简单，更加快捷。

官方也推荐我们直接基于SpringBoot来进行一个快速入门，原因见上。

SpringBoot框架的两大核心：

SpringBoot框架之所以使用起来更简单更快捷，是因为SpringBoot框架底层提供了两个非常重要的功能：一个是起步依赖，一个是自动配置。

通过SpringBoot所提供的起步依赖，就可以大大的简化pom文件当中依赖的配置，从而解决了Spring框架当中依赖配置繁琐的问题。
通过自动配置的功能就可以大大的简化框架在使用时bean的声明以及bean的配置。我们只需要引入程序开发时所需要的起步依赖，项目开发时所用到常见的配置都已经有了，我们直接使用就可以了。

学习SpringBoot的原理就是来解析SpringBoot当中的起步依赖与自动配置的原理。我们首先来学习SpringBoot当中起步依赖的原理。

3.1 起步依赖

假如我们没有使用SpringBoot，用的是Spring框架进行web程序的开发，此时我们就需要引入web程序开发所需要的一些依赖。

原始的Spring框架进行Web程序的开发

spring-webmvc依赖：这是Spring框架进行web程序开发所需要的依赖
servlet-api依赖：Servlet基础依赖(因为SpringMVC要对Servlet进行封装)
jackson-databind依赖：JSON处理工具包
如果要使用AOP，还需要引入aop依赖、aspect依赖
项目中所引入的这些依赖，还需要保证版本匹配，否则就可能会出现版本冲突问题。

如果我们使用了SpringBoot，就不需要像上面这么繁琐的引入依赖了。我们只需要引入一个依赖就可以了，那就是web开发的起步依赖：springboot-starter-web。只要引入这个Starter，我们就可以轻松的创建并启动个一个SpringBoot Web应用。

什么是Starter？

Starter，是"一站式服务(one-stop) "的依赖Jar包：

包含Spring以及相关技术(比如Redis)的所有依赖
提供了自动配置的功能，遵从"约定优于配置"的原则，开发人员可以在少量配置甚至不配置的情况下，开箱即用某个组件
提供了良好的依赖管理，避免了包遗漏、版本冲突等问题

Starter的架构图

一个Starter由两个Moudle模块组成，分别是starter模块和autoconfigure模块，其中，starter模块会依赖autoconfigure模块，同时它也会依赖第三方组件中的Jar包。
而autoconfigure模块也会依赖第三方组件的Jar包。

Maven中的Optional可选依赖

为什么我们只需要引入一个web开发的起步依赖，web开发所需要的所有的依赖都有了呢？

因为Maven的依赖传递。

在SpringBoot给我们提供的这些起步依赖当中，已提供了当前程序开发所需要的所有的常见依赖(官网地址：Spring Boot Reference Documentation)。
比如：springboot-starter-web，这是web开发的起步依赖，在Web开发的起步依赖当中，就集成了web开发中常见的依赖：json、web、webmvc、tomcat等。我们只需要引入这一个起步依赖，其他的依赖都会自动的通过Maven的依赖传递进来。

结论：起步依赖的原理就是Maven的依赖传递。

3.2 自动配置

回顾：SpringBoot当中起步依赖的原理，就是Maven的依赖传递。

接下来我们解析下自动配置的原理，我们要分析自动配置的原理，首先要知道什么是自动配置。

3.2.1 概述

SpringBoot自动配置，英文是Auto-Configuration：

它是指基于你引入的依赖Jar包，对SpringBoot应用进行自动配置
它为SpringBoot框架"开箱即用" 提供了基础支撑

注意：区分自动配置和自动装配

自动配置：Auto-Configuration，针对的是SpringBoot中的配置类。
自动装配：Autowire，针对的是Spring中的依赖注入。

术语："配置类"，英文Configuration Class：

广义的"配置类" ：被注解@Component直接或间接修饰的某个类，即我们常说的Spring组件，其中包括了@Configuration类。
狭义的"配置类" ：特指被注解@Configuration所修饰的某个类，又称为@Configuration类

SpringBoot的自动配置就是当Spring容器启动后，一些配置类、bean对象就自动存入到了IOC容器中，不需要我们手动去声明，从而简化了开发，省去了繁琐的配置操作。

下面我们打开IDEA，一起来看下自动配置的效果：

运行SpringBoot启动类

由于在CommonConfig配置类上添加了一个注解@Configuration，而@Configuration底层就是@Component，所以配置类最终也是SpringIOC容器当中的一个bean对象。

在IOC容器中除了我们自己定义的bean以外，还有很多配置类，这些配置类都是SpringBoot在启动的时候加载进来的配置类。这些配置类加载进来之后，它也会生成很多的bean对象。

并且SpringBoot在启动的时候加载进来的配置类，也就是黄色背景的类，它们的后缀名有一个规范，基本上都是AutoConfiguration，翻译过来就是自动配置！要么就是Configuration!

比如：配置类GsonAutoConfiguration里面有一个bean，bean的名字叫gson，它的类型是Gson。
com.google.gson.Gson是谷歌包中提供的用来处理JSON格式数据的。

当我们想要使用这些配置类中生成的bean对象时，可以使用@Autowired就自动注入了：

    @Autowired
    private Gson gson; // 谷歌提供改的一个用来JSON处理的工具包

    @Test
    public void testJson() {
        // GSON可以将一个对象直接转为JSON格式的数据
        System.out.println(gson.toJson(Result.success()));
    }

问题：在当前项目中我们并没有声明谷歌提供的Gson这么一个bean对象，然后我们却可以通过@Autowired从Spring容器中注入bean对象，那么这个bean对象怎么来的？

答案：SpringBoot项目在启动时通过自动配置完成了bean对象的创建。

体验了SpringBoot的自动配置了，下面我们就来分析自动配置的原理。其实分析自动配置原理就是来解析在SpringBoot项目中，在引入依赖之后是如何将依赖jar包当中所定义的配置类以及bean加载到SpringIOC容器中的。

3.2.2 常见方案

3.2.2.1 概述

我们知道了什么是自动配置之后，接下来我们就要来剖析自动配置的原理。解析自动配置的原理就是分析在 SpringBoot项目当中，我们引入对应的依赖之后，是如何将依赖jar包当中所提供的bean以及配置类直接加载到当前项目的SpringIOC容器当中的。

接下来，我们就直接通过代码来分析自动配置原理。

引入第三方依赖后，在测试类中从IOC容器中手动获取Bean对象：

异常信息描述：NoSuchBeanDefinitionException 没有com.example.TokenParse此类型的bean

说明：在Spring容器中没有找到com.example.TokenParse类型的bean对象

思考：手动引入进来的第三方依赖当中的bean以及配置类为什么没有生效？

基于@Component注解所声明的Bean必须要被组件扫描到，如果扫描不到，就必须手动扫描
原因在我们之前学习IOC的时候有提到过，在类上添加@Component注解来声明bean对象时，还需要保证@Component注解能被Spring的组件@ComponentScan扫描到。
SpringBoot项目中的@SpringBootApplication注解，具有包扫描的作用，但是它只会扫描启动类所在的当前包以及子包。

那么如何解决以上问题的呢？

方案1：在SpringBoot启动类上添加@ComponentScan 组件扫描
方案2：在SpringBoot引导类上添加@Import注解导入（使用@Import注解导入的类会被Spring加载到IOC容器中）

3.2.2.2 方案一

@ComponentScan组件扫描：一旦手动指定，就把原来的包扫描默认值覆盖掉了。

@SpringBootApplication
// @ComponentScan(basePackages = {"com.gch"})
@ComponentScan({"com.gch","com.example"}) //指定要扫描的包
public class SpringbootWebConfig2Application {
    public static void main(String[] args) {
        SpringApplication.run(SpringbootWebConfig2Application.class, args);
    }
}

大家可以想象一下，如果采用以上这种方式来完成自动配置，那我们进行项目开发时，当需要引入大量的第三方的依赖，就需要在启动类上配置N多要扫描的包，这种方式会很繁琐。而且这种大面积的扫描性能也比较低。

缺点：

使用繁琐

扫描包越多，性能越低

结论：SpringBoot中并没有采用以上这种方案。

3.2.2.3 方案二

@Import注解导入：使用@Import注解导入的类会被Spring加载到IOC容器当中！

Spring容器启动时：加载IOC容器时会解析@Import注解！

导入形式主要有以下几种：
1. 导入普通类{没有加任何注解的类}
2. 导入配置类{类上面加了@Configuration注解的类}
3. 导入 ImportSelector接口实现类

1）演示使用@Import注解导入普通类：

package com.gch;

import org.springframework.context.annotation.Import;

/**
   被@Import注解导入的类会被Spring加载到IOC容器当中
 */
// 导入普通类
@Import(TokenParser.class)
@SpringBootApplication
public class TliasWebManagementApplication {

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

2). 使用@Import注解导入配置类：

package com.gch;

import org.springframework.context.annotation.Import;

/**
   被@Import注解导入的类会被Spring加载到IOC容器当中
 */
// 导入配置类,配置类当中所有的bean都会导入进来，被加载到Spring的IOC容器当中
@Import({CommonConfig.class, WebConfig.class})
@SpringBootApplication
public class TliasWebManagementApplication {

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

3). 使用@Import注解导入ImportSelector接口实现类：

ImportSelector接口实现类

package com.gch;

import org.springframework.context.annotation.ImportSelector;
import org.springframework.core.type.AnnotationMetadata;

/**
 * ImportSelector接口实现类
 */
public class MyImportSelector implements ImportSelector {
    /**
     * @param importingClassMetadata
     * @return 字符数组当中封装了哪些类应该被导入到IOC容器当中,字符数组当中封装了类的全类名
     */
    @Override
    public String[] selectImports(AnnotationMetadata importingClassMetadata) {
        //返回值字符串数组（数组中封装了全限定名称的类）
        return new String[]{"com.gch.config.CommonConfig"};
    }
}

启动类

package com.gch;

/**
   被@Import注解导入的类会被Spring加载到IOC容器当中
 */
// 导入ImportSelector接口实现类,相当于批量导入
@Import(MyImportSelector.class)
@SpringBootApplication
public class TliasWebManagementApplication {

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

我们使用@Import注解通过这三种方式都可以导入第三方依赖中所提供的bean或者是配置类。

思考：如果基于以上方式完成自动配置，当要引入一个第三方依赖时，是不是还要知道第三方依赖中有哪些配置类和哪些Bean对象？

答案：是的。（对程序员来讲，很不友好，而且比较繁琐）

思考：当我们要使用第三方依赖，依赖中到底有哪些bean和配置类，谁最清楚？

答案：第三方依赖自身最清楚。

结论：我们不用自己指定要导入哪些bean对象和配置类了，让第三方依赖它自己来指定。

怎么让第三方依赖自己指定bean对象和配置类？

比较常见的方案就是第三方依赖给我们提供一个注解，自己去封装一个注解，这个注解一般都以@EnableXxxx开头的注解，注解中封装的就是@Import注解

4). 使用第三方依赖提供的 @EnableXxxxx注解

第三方依赖中提供的注解 / 自定义的注解

package com.gch;

import org.springframework.context.annotation.Import;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

/**
 * 自定义注解
 * 该注解指定要导入哪些bean对象和配置类,该注解封装了@Import注解
 * 使用@Import注解导入ImportSelector接口实现类,指定要导入哪些bean对象或者是配置类
 * 被@Import注解导入的类会被Spring加载到IOC容器当中
 */
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Import(MyImportSelector.class)
public @interface EnableImport {
}

在使用时只需在启动类上加上@EnableXxxxx注解即可

package com.gch;

/**
   被@Import注解导入的类会被Spring加载到IOC容器当中
 */
    
// 使用第三方依赖提供的Enable开头的注解
@EnableImport
@SpringBootApplication
public class TliasWebManagementApplication {
    public static void main(String[] args) {
        SpringApplication.run(TliasWebManagementApplication.class, args);
    }
}

以上四种方式都可以完成导入操作，但是第4种方式 - 自定义@EnableXxx开头的注解会更方便更优雅，而这种方式也是SpringBoot当中所采用的方式。

3.2.3 原理分析

3.2.3.1 源码跟踪

前面我们学习了在项目当中引入第三方依赖之后，如何加载第三方依赖中定义好的bean对象以及配置类，从而完成自动配置操作。

那下面我们通过源码跟踪的形式来剖析下SpringBoot底层到底是如何完成自动配置的。

源码跟踪技巧：

在跟踪框架源码的时候，一定要抓住关键点，找到核心流程。一定不要从头到尾一行代码去看，一个方法的去研究，一定要找到关键流程，抓住关键点，先在宏观上对整个流程或者整个原理有一个认识，有精力再去研究其中的细节。

我们要运行所有的SpringBoot项目，首先分析入口在哪里？

入口在启动类 / 引导类

又提问：怎么标识这是一个启动类呢？

通过注解@SpringBootApplication来标识

要搞清楚SpringBoot的自动配置原理，要从SpringBoot启动类上使用的核心注解@SpringBootApplication开始分析，@SpringBootApplication它是一个组合注解：

@SpringBootApplication的源码

在@SpringBootApplication注解中包含了：

元注解（不再解释）
@SpringBootConfiguration：底层封装了@Configuration注解，@Configuration注解就是用来标识当前类是Spring当中的配置类，那么@SpringBootApplication顾名思义就是用来标识当前类是一个SpringBoot的配置类，我们可以把第三方bean配置到启动类当中，原因就是因为启动类是一个配置类。
@EnableAutoConfiguration：Enable开头的注解，用于启用SpringBoot的自动配置机制，它会根据应用的依赖和配置情况，自动配置和装配Spring应用程序的各种组件，简化了SpringBoot应用程序的配置过程，并提供了默认的配置。
@ComponentScan：组件 / 包扫描注解

这些注解的组合使得@SpringBootApplication注解可以快速启动一个SpringBoot应用程序，自动配置Spring应用程序的各种组件，扫描并加载相关的其它组件。

我们先来看第一个注解：@SpringBootConfiguration

@SpringBootConfiguration注解底层封装了@Configuration注解，表明SpringBoot启动类就是一个配置类。
@Indexed注解，是用来加速应用启动的（不用关心）。

接下来再先看@ComponentScan注解：

@ComponentScan注解是用来进行组件扫描的，扫描启动类所在的包及其子包下所有被@Component及其衍生注解声明的类。
SpringBoot启动类，之所以具备扫描包功能，就是因为包含了@ComponentScan注解。

最后我们来看看@EnableAutoConfiguration注解（自动配置核心注解）：

@EnableAutoConfiguration注解底层封装了@Import注解，导入了实现ImportSelector接口的实现类。
AutoConfigurationImportSelector类是ImportSelector接口的实现类。

AutoConfigurationImportSelector类中重写了ImportSelector接口的selectImports()方法：

selectImports()方法底层调用getAutoConfigurationEntry()方法，获取可自动配置的配置类信息集合

getAutoConfigurationEntry()方法底层通过调用getCandidateConfigurations(annotationMetadata, attributes)方法获取在配置文件中配置的所有自动配置类的集合！

getCandidateConfigurations方法的功能：

获取所有基于META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件、META-INF /spring.factories文件中配置类的信息并封装到List集合configurations当中。

在 META-INF / spring.factory 和 META-INF / springorg.springframework.boot.autoconfigure.AutoConfiguration.imports 中找不到自动配置类。

最终将List集合当中的内容再封装到String类型的数组当中，而String类型的数组当中所封装的数据最终是要加载到IOC容器当中的bean或者是配置类。

META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件和META-INF/spring.factories文件这两个文件在哪里呢？

通常在引入的起步依赖中，都有包含以上两个文件

经过观察，不止一个依赖是以autoconfigure结尾，也就是说这些进行自动配置的依赖，它们有一个共同点就是以autoconfigure结尾，它们的后缀都是autoconfigure。

在外部库中找到spring-boot-autoconfigure这项依赖，就可以找到上面的两份文件，在spring目录下的AutoConfiguration.imports文件以及spring.factories文件：

spring.factories当中并没有配置自动配置类，里面大多数是一些Listener监听器、Filter过滤器：

在AutoConfiguration.imports这份配置文件当中配置的都是类的全类名，都是以AutoConfiguration结尾，翻译过来为自动配置！

总共有144个配置类，一个配置类当中又有若干个Bean对象

AutoConfiguration.imports这份配置文件最终会被读取出来，并且通过@Import注解会加载到Spring的IOC容器当中，交给IOC容器进行管理。

在前面在给大家演示自动配置的时候，我们直接在测试类当中注入了一个叫gson的bean对象，可以进行JSON格式转换。虽然我们没有配置bean对象，但是我们是可以直接注入使用的。

原因就是因为在自动配置类当中做了自动配置。

到底是在哪个自动配置类当中做的自动配置呢？我们通过按Ctrl + F搜索来查询一下。

在META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports配置文件中指定了第三方依赖Gson的配置类：GsonAutoConfiguration - Gson自动配置类

第三方依赖中提供的GsonAutoConfiguration类：

看到这里，大家就应该明白为什么可以完成自动配置了，原理就是在配置类中定义一个@Bean标识的方法，而Spring会自动调用在配置类当中使用了@Bean注解标识的方法，并把方法的返回值加载到Spring的IOC容器当中。

自动配置源码小结

自动配置原理源码入口就是@SpringBootApplication注解，该注解标识在SpringBoot工程的启动类 / 引导类上，是SpringBoot中最最最重要的注解，该注解由三个部分组成，是一个组合注解，在这个注解中封装了3个注解，分别是：

@SpringBootConfiguration
- 底层封装了@Configuration注解，@Configuration注解作用就是用来声明当前类是Spring当中的一个配置类，顾名思义@SpringBootConfiguration就是用来声明当前类是SpringBoot当中的一个配置类
@ComponentScan
- 进行组件扫描（SpringBoot中默认扫描的是启动类所在的当前包及其子包）
@EnableAutoConfiguration：负责启动自动配置功能
- 是SpringBoot实现自动化配置的核心注解
- 封装了@Import注解（Import注解中指定了一个ImportSelector接口的实现类）
  - 在实现类重写的selectImports()方法，读取当前项目下所有依赖jar包中META-INF/spring.factories、META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports两个文件里面定义的配置类（配置类中定义了很多@Bean注解标识的方法）。

selectImports()方法的返回值是一个String类型的数组，在这个数组当中封装的就是我要导入到Spring IOC容器当中的类的全类名。

当SpringBoot程序启动时，就会加载配置文件当中所定义的配置类，并将这些配置类信息(类的全限定名)封装到String类型的数组中，最终通过@Import注解将这些配置类全部加载到Spring的IOC容器中，交给IOC容器管理。

说明：spring.factories这个文件是Spring Boot早期自动配置所加载的文件，而在Spring Boot 2.7.0版本之后，就提供了一份全新的自动配置的文件，也就是AutoConfiguration.imports，

在Spring Boot 3.0版本之前，它还会兼容之前的spring.factories这个文件，但是在Spring Boot 3.0版本之后，spring.factories这个文件就会被彻底的移除掉，所以我们现在导入的配置类就直接定义在AutoConfiguration.imports这个文件当中，这个文件当中定义的就是配置类的全类名，在配置类当中，我们就可以通过@Bean注解标识的方法来声明一个一个的Bean对象，最终SpringBoot项目在启动的时候，它就会加载这个配置文件当中所配置的这些配置类，然后将这些配置类的信息封装到这个String类型的数组当中，最终通过@Import注解将这些配置类全部加载到Spring的IOC容器当中，交给IOC容器进行管理。

最后呢给大家抛出一个问题：在META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件中定义的配置类非常多，而且每个配置类中又可以定义很多的bean，那这些bean都会注册到Spring的IOC容器中吗？

答案：并不是。 在声明bean对象时，上面有加一个以@Conditional开头的注解， 举例@ConditionalOnMissingBean ，这种注解的作用就是按照条件进行装配，只有满足条件之后，才会将bean对象注册加载到Spring的IOC容器中（下面会详细来讲解）

@Conditional注解是如何进行条件装配的？

3.2.3.2 @Conditional

我们在跟踪SpringBoot自动配置的源码的时候，在自动配置类声明bean的时候，除了在方法上加了一个@Bean注解以外，还会经常用到一个注解，就是以@Conditional开头的这一类的注解。以@Conditional开头的这些注解都是条件装配的注解。

下面我们就来介绍下条件装配注解@Coniditional。

@Conditional注解：

作用：按照一定的条件进行判断，在满足给定条件后才会注册对应的bean对象并加载到 Spring的IOC容器中。
位置：方法、类
如果作用在方法上，代表只是针对于当前方法声明的Bean有效
如果作用在类上，代表针对于整个配置类都有效。
@Conditional本身是一个父注解，它派生出了大量的子注解：

@ConditionalOnClass：判断当前环境中是否有对应字节码文件，如果有，才注册bean对象并加载到Spring的IOC容器当中。基于该注解就可以很轻松的实现自动配置的功能，只要我们在pom文件当中引入了对应的依赖，那这个bean就自动的配置好了，我们不需要做任何的操作。
@ConditionalOnMissingBean：判断环境中没有对应的bean(类型或名称)，才注册bean到Spring的IOC容器。
@ConditionalOnProperty：判断配置文件中有对应属性(名)和(属性)值，才注册bean对象到Spring的IOC容器当中。

下面我们通过代码来演示下Conditional注解的使用：

@ConditionalOnClass注解

@Configuration
public class HeaderConfig {

    @Bean
    //环境中存在指定的字节码文件 / 这个类，才会将该bean加入IOC容器
    @ConditionalOnClass(name="io.jsonwebtoken.Jwts")
    public HeaderParser headerParser(){
        return new HeaderParser();
    }
    
    //省略其他代码...
}

@ConditionalOnMissingBean注解：根据声明的bean的类型来判断

@Configuration
public class HeaderConfig {

    @Bean
    //不存在该HeaderParse类型的bean，才会将该bean加入IOC容器
    @ConditionalOnMissingBean 
    public HeaderParser headerParser(){
        return new HeaderParser();
    }
    
    //省略其他代码...
}

再次修改@ConditionalOnMissingBean注解：根据指定名称的bean来判断(通过注解的value属性)

@Configuration
public class HeaderConfig {

    @Bean
    //不存在指定名称的bean，才会创建HeaderParse对象将该bean加入IOC容器
    @ConditionalOnMissingBean(name="deptController2")
    public HeaderParser headerParser(){
        return new HeaderParser();
    }
    
    //省略其他代码...
}

再次修改@ConditionalOnMissingBean注解：根据指定类型的bean来判断(通过注解的name属性)

@Configuration
public class HeaderConfig {

    @Bean
    //不存在指定类型的bean，才会创建HeaderParser对象将bean加入IOC容器
    @ConditionalOnMissingBean(HeaderConfig.class)
    public HeaderParser headerParser(){
        return new HeaderParser();
    }
    
    //省略其他代码...
}

因为HeaderConfig类中添加@Configuration注解 ，而@Configuration注解中包含了@Component，所以SpringBoot启动时会创建HeaderConfig类对象，并注册到IOC容器中。
当IOC容器中有HeaderConfig类型的bean存在时，不会把创建HeaderParser对象注册到IOC容器中。而IOC容器中没有HeaderParser类型的对象时，通过getBean(HeaderParser.class)方法获取bean对象时，引发异常：NoSuchBeanDefinitionException

@ConditionalOnMissingBean注解的应用场景：通常是用来设置一个默认的bean对象。

什么是默认的bean对象呢？

所谓默认的bean对象指的就是如果用户在引入我们这个依赖之后，·他自己定义了这个类型的Bean，那此时就用他自己定义的，默认的就不会生效了；如果说他没有自己定义，然而他还想使用这个类型的bean，那此时就使用我们所提供的默认的这个Bean就可以了。

@ConditionalOnProperty注解（这个注解和配置文件当中配置的属性有关系）

先在application.yml配置文件中添加如下的键值对：

在声明bean的时候就可以指定一个条件@ConditionalOnProperty

@Configuration
public class HeaderConfig {

    @Bean
    //配置文件中存在指定属性名与值，才会将bean加入IOC容器
    //name指的是配置文件当中配置项的Key havingValue指的就是配置项的值
    @ConditionalOnProperty(name ="name",havingValue = "gch")
    public HeaderParser headerParser(){
        return new HeaderParser();
    }

    @Bean
    public HeaderGenerator headerGenerator(){
        return new HeaderGenerator();
    }
}

@ConditionalOnProperty注解的使用场景： 比如，我们在SpringBoot当中，在整合一些其它的第三方技术的时候，我们只有在对应的配置文件当中配置了对应的配置项，它才会声明对应的Bean对象！

我们再回头看看之前讲解SpringBoot源码时提到的一个配置类：GsonAutoConfiguration

最后再梳理一下自动配置原理：

自动配置的核心就在@SpringBootApplication注解上，@SpringBootApplication这个注解底层封装了3个注解，分别是：

@SpringBootConfiguration

@ComponentScan

@EnableAutoConfiguration

@EnableAutoConfiguration这个注解才是Spring Boot自动配置的核心。

它底层封装了一个@Import注解，@Import注解里面指定了一个ImportSelector接口的实现类。

在这个实现类中，重写了ImportSelector接口中的selectImports()方法。

而selectImports()方法中会去读取两份配置文件，并将配置文件中定义的配置类做为selectImports()方法的返回值返回，返回值代表的就是需要将哪些类交给Spring的IOC容器进行管理。

那么所有自动配置类当中通过@Bean注解声明的bean都会加载到Spring的IOC容器中吗?

其实并不会，因为这些配置类中在声明bean时，通常都会添加@Conditional开头的注解，这个注解就是进行条件装配。而Spring会根据Conditional注解有选择性的进行bean的创建。

@Enable开头的注解，底层它就封装了一个@Import 注解，它里面指定了一个类，是 ImportSelector 接口的实现类。在实现类当中，我们需要去实现 ImportSelector 接口当中的一个方法 selectImports() 这个方法。这个方法的返回值代表的就是我需要将哪些类交给 Spring 的 IOC容器进行管理。

此时它会去读取两份配置文件，一份儿是 spring.factories，另外一份儿是 autoConfiguration.imports。而在 autoConfiguration.imports 这份儿文件当中，过滤出所有@AutoConfigurationClass类型的类，它就会去配置大量的自动配置的类。

而前面我们也提到过这些所有的自动配置类当中，所有的 bean都会加载到 Spring 的 IOC 容器当中吗？

其实并不会，因为这些配置类当中，在声明 bean 的时候，通常会加上这么一类 @Conditional 开头的注解。这个注解就是进行条件装配。所以SpringBoot非常的智能，它会根据 @Conditional 注解来进行条件装配。只有条件成立，它才会声明这个bean，才会将这个 bean 交给 IOC 容器管理。

最后通过@Conditional排除无效的自动配置类。

Spring Boot启动流程简化版：

3.2.4 案例

3.2.4.1 自定义starter分析

前面我们解析了SpringBoot中自动配置的原理，下面我们就通过一个自定义starter案例来加深大家对于自动配置原理的理解。首先介绍一下自定义starter的业务场景，再来分析一下具体的操作步骤。

所谓starter指的就是SpringBoot当中的起步依赖。

在SpringBoot当中已经给我们提供了很多的起步依赖了，我们为什么还需要自定义 starter 起步依赖？

这是因为在实际的项目开发当中，我们可能会用到很多第三方的技术，并不是所有的第三方的技术官方都给我们提供了与SpringBoot整合的starter起步依赖，但是这些技术又非常的通用，在很多项目组当中都在使用。

在实际开发中，经常会定义一些公共组件(即自定义starter)，提供给各个项目团队使用。

在SpringBoot项目中，一般都会将这些公共组件封装为SpringBoot当中的starter，也就是我们所说的起步依赖。

如果是SpringBoot官方提供的stater起步依赖，它的规范都是spring-boot-starter-xxx对应的功能

SpringBoot官方starter命名： spring-boot-starter-xxxx

如果该起步依赖不是Spring Boot官方提供的，而是第三方主动整合的Spring Boot提供的starter起步依赖，它的命名规范一般都是功能在前，比如：mybatis-spring-boot-starter，一看就知道这是MyBatisz整合SpringBoot所提供的起步依赖。

第三组织提供的starter命名： xxxx-spring-boot-starter

以后，在项目开发时，就可以通过该规范区分出来到底是SpringBoot官方提供的，还是其它第三方技术整合SpringBoot所提供的starter起步依赖。

**举例：我们来看一下MyBatis的起步依赖：mybatis-spring-boot-**starter - 依赖管理功能

我们可以看到该starter起步依赖当中一个Java代码都没有，其实这个starter起步依赖当中它就做了一件事情，就是将MyBatis开发所需要的这些依赖配置到配置文件当中。

在starter起步依赖当中 ， 引入****有一项比较特殊的依赖 - autoconfigure ，该依赖提供了一些自动配置类 - 完成自动配置操作

mybatis-spring-boot-autoconfigure依赖当中的MybatisAutoConfiguration自动配置类中的sqlSessionFactory()方法声明了@Bean注解，声明了sqlSessionFactory这样的@Bean对象

Mybatis提供了配置类，并且也提供了Springboot会自动读取的配置文件。当SpringBoot项目启动时，会读取到spring.factories配置文件中的配置类并加载配置类，生成相关bean对象注册到IOC容器中。

结果：我们可以直接在SpringBoot程序中使用Mybatis自动配置的bean对象。

我们在自定义一个starter起步依赖的时候，按照规范需要定义两个模块：

starter模块（进行依赖管理[把程序开发所需要的依赖都定义在starter起步依赖中]）
autoconfigure模块（完成自动配置操作）

最终在starter模块当中，需要将autoconfigure这个自动配置的模块要引入进来！

因此将来在项目当中进行相关功能开发时，只需要引入一个starter起步依赖就可以了，因为它会将autoconfigure自动配置的依赖给传递下来[Maven当中的依赖传递]。

上面我们简单介绍了自定义starter的场景，以及自定义starter时涉及到的模块之后，接下来我们就来完成一个自定义starter的案例。

需求： 自定义aliyun-oss-spring-boot-starter，完成阿里云OSS操作工具类 - AliyunOSSUtils的自动配置。

目标： 引入起步依赖引入之后，要想使用阿里云OSS，注入AliyunOSSUtils直接使用即可。

业务场景：

我们前面案例当中所使用的阿里云OSS对象存储服务，现在阿里云的官方是没有给我们提供对应的起步依赖的，这个时候使用起来就会比较繁琐，我们需要引入对应的依赖，我们还需要在配置文件当中进行配置，还需要基于官方SDK示例来改造对应的工具类，我们在项目当中才可以进行使用。
大家想在我们当前项目当中使用了阿里云OSS，我们需要进行这么多步的操作。在别的项目组当中要想使用阿里云OSS，是不是也需要进行这么多步的操作，所以这个时候我们就可以自定义一些公共组件(自定义starter)，在这些公共组件当中，我就可以提前把需要配置的bean都提前配置好。将来在项目当中，我要想使用这个技术，我直接将组件对应的坐标直接引入进来，就已经自动配置好了，就可以直接使用了。我们也可以把公共组件提供给别的项目组进行使用，这样就可以大大的简化我们的开发。

所以这个时候我们就可以制作一个公共组件(自定义starter)。starter定义好之后，将来要使用阿里云OSS进行文件上传，只需要将起步依赖引入进来之后，就可以直接注入AliOSSUtils使用了。

需求明确了，接下来我们再来分析一下具体的实现步骤：

第1步：创建自定义starter模块（进行依赖管理）
- 把阿里云OSS所有的依赖统一管理起来
第2步：创建autoconfigure模块(进行自动配置操作)
- 在starter中引入autoconfigure （我们使用时只需要引入starter起步依赖即可）
第3步：在autoconfigure模块中完成自动配置
1. 定义一个自动配置类，在自动配置类中将所要配置的bean都提前配置好
2. 定义配置文件，把自动配置类的全类名定义在配置文件中

我们分析完自定义阿里云OSS自动配置的操作步骤了，下面我们就按照分析的步骤来实现自定义starter。

3.2.4.2 自定义starter实现

自定义Starter最重要的是要遵循SPI机制， 在resopurces目录下创建文件夹META-INF，并在META-INF下创建文件spring.factories，内容如下：

自定义starter的步骤我们刚才已经分析了，接下来我们就按照分析的步骤来完成自定义starter的开发。

首先我们先来创建两个Maven模块：

1). aliyun-oss-spring-boot-starter模块：什么依赖都不选，只指定Spring Boot的版本

SpringBoot的版本后期可以改为2.7.5！

starter模块仅仅进行依赖管理，里面没有任何的Java代码，因此也将src目录删掉。

创建完starter模块后，删除多余的文件，iml文件别删，这是IDEA的配置文件，最终保留内容如下：

删除pom.xml文件中多余的内容，包括<name>和<description>这两项描述信息，<plugins>插件以及SpringBoot整合单元测试的依赖：

2). aliyun-oss-spring-boot-autoconfigure模块指定Spring Web的起步依赖以及Lombok依赖

精简pom.xml文件中多余的内容：包括<name>和<description>这两项描述信息，<plugins>插件以及SpringBoot整合单元测试的依赖

由于autoconfigure模块我们是需要编写自动配置的代码的，所以src目录保留，iml文件同样保留，其它删掉：

由于autoconfigure模块将来是要作为第三方模块被其它项目所依赖的，所以该模块的启动类我们是不需要的，因此手动删除，test测试目录也不需要，因此也可删除。

按照我们之前的分析，是需要在starter模块中来引入autoconfigure这个模块的。打开starter模块中的pom.xml文件，来引入autoconfigure模块：

   <dependencies>
        
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
        </dependency>
        
        <dependency>
            <groupId>com.aliyun.oss</groupId>
            <artifactId>aliyun-oss-spring-boot-autoconfigure</artifactId>
            <version>0.0.1-SNAPSHOT</version>
        </dependency>
        
    </dependencies>

前两步已经完成了，接下来是最关键的就是第三步：在autoconfigure模块当中来完成自动配置操作。

先将阿里云OSS的相关依赖拷贝到 autoconfigure模块的pom.xml配置文件当中：

 <!-- 阿里云OSS Java SDK-->
        <dependency>
            <groupId>com.aliyun.oss</groupId>
            <artifactId>aliyun-sdk-oss</artifactId>
            <version>3.15.1</version>
        </dependency>
        <!-- jaxb相关依赖-->
        <dependency>
            <groupId>javax.xml.bind</groupId>
            <artifactId>jaxb-api</artifactId>
            <version>2.3.1</version>
        </dependency>
        <dependency>
            <groupId>javax.activation</groupId>
            <artifactId>activation</artifactId>
            <version>1.1.1</version>
        </dependency>
        <!-- no more than 2.3.3-->
        <dependency>
            <groupId>org.glassfish.jaxb</groupId>
            <artifactId>jaxb-runtime</artifactId>
            <version>2.3.3</version>
        </dependency>

我们再将之前案例中所使用的阿里云OSS部分的代码直接拷贝到autoconfigure模块下，然后进行改造就行了。

现在大家思考下，在类上添加的@Component注解还有用吗？

答案：没用了。因为在SpringBoot项目中，我们并不会去扫描com.aliyun.oss这个包，不扫描这个包那类上的注解也就失去了作用。

@Component注解不需要使用了，可以从类上删除了。

删除后报红色错误，暂时不理会，后面再来处理。

删除AliOSSUtils类中的@Component注解、@Autowired注解

下面我们就要自定义一个自动配置类了，在自动配置类当中来声明AliOSSUtils的bean对象。

AliOSSAutoConfiguration类：

package com.aliyun.oss;

import org.springframework.boot.context.properties.EnableConfigurationProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * 自动配置类
 */
@Configuration // 当前类为Spring当中的配置类
// 该注解只能加在一个具有@Bean注解声明的方法上或者是一个配置类上
// 导入AliyunOSSProperties类,并交给Spring的IOC容器管理
@EnableConfigurationProperties(AliyunOSSProperties.class) 
public class AliOSSAutoConfiguration {
    @Bean
    public AliyunOSSUtils aliyunOSSUtils(AliyunOSSProperties aliyunOSSProperties) {
        AliyunOSSUtils aliyunOSSUtils = new AliyunOSSUtils();
        aliyunOSSUtils.setAliyunOSSProperties(aliyunOSSProperties);
        return aliyunOSSUtils;
    }
}

AliOSSProperties类：

package com.aliyun.oss;

import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties;

/**
   阿里云OSS相关配置:将配置文件当中配置项的值自动的注入到bean对象的属性当中
 */
@Data
@ConfigurationProperties(prefix = "aliyun.oss")
public class AliyunOSSProperties {
    /** 指定连接的阿里云OSS对象存储服务的域名/地址 */
    private String endpoint;
    /** 阿里云OSS账号AccessKey身份ID */
    private String accessKeyId;
    /** 阿里云OSS账号AccessKey身份ID对应的密钥 */
    private String accessKeySecret;
    /** 存储空间Bucket的名称 */
    private String bucketName;
}

AliOSSUtils类：

package com.aliyun.oss;

import com.aliyun.oss.model.PutObjectRequest;
import com.aliyun.oss.model.PutObjectResult;
import org.springframework.web.multipart.MultipartFile;

import java.io.IOException;
import java.util.UUID;

/**
   使用阿里云OSS进行文件存储的工具类
 */
public class AliyunOSSUtils {
    /** 声明配置参数实体类对象 */
    private AliyunOSSProperties aliyunOSSProperties;

    public AliyunOSSProperties getAliyunOSSProperties() {
        return aliyunOSSProperties;
    }

    public void setAliyunOSSProperties(AliyunOSSProperties aliyunOSSProperties) {
        this.aliyunOSSProperties = aliyunOSSProperties;
    }

    /**
     * 实现文件上传到OSS
     * @param multipartFile 在服务端来接收到上传的文件
     * @return 返回图片访问的URL
     * @throws IOException
     */
    public String upload(MultipartFile multipartFile) throws IOException {
        // 获取阿里云OSS参数
        String endpoint = aliyunOSSProperties.getEndpoint();
        String accessKeyId = aliyunOSSProperties.getAccessKeyId();
        String accessKeySecret = aliyunOSSProperties.getAccessKeySecret();
        String bucketName = aliyunOSSProperties.getBucketName();

        /** 构造唯一的文件对象名称:UUID + 文件扩展名 */
        String objectName = UUID.randomUUID().toString() + multipartFile.getOriginalFilename().substring(multipartFile.getOriginalFilename().lastIndexOf("."));

        // 创建OSSClient实例。
        OSS ossClient = new OSSClientBuilder().build(endpoint,accessKeyId,accessKeySecret);

        try {
            // 创建PutObjectRequest对象。
            PutObjectRequest putObjectRequest = new PutObjectRequest(bucketName, objectName, multipartFile.getInputStream());
            // 上传文件到OSS
            PutObjectResult result = ossClient.putObject(putObjectRequest);
        } finally {
            if (ossClient != null) {
                // 关闭ossClient
                ossClient.shutdown();
            }
        }
        // 返回文件访问路径
        return endpoint.split("//")[0] + "//" + bucketName + "." + endpoint.split("//")[1] + "/" + objectName;
    }
}

重点来了：自动配置类要想被加载到，那就需要在一份固定的配置文件当中来配置，SpringBoot在启动时就会来加载这份儿配置文件，这份儿配置文件是需要定义在classpath类路径下，所以直接在resources目录下来新建一级目录：META-INF/spring

在aliyun-oss-spring-boot-autoconfigure模块中的resources下，新建自动配置文件：

META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

在该配置文件当中来配置自动配置类的全类名：

总结：starter模块当中就是进行依赖管理的，autoconfigure模块就是来实现自动配置的！

我们需要定义自动配置类，将需要自动配置的Bean都定义在这个自动配置类当中，然后在配置文件AutoConfiguration.imports当中来配置自动配置类的全类名，将来SpringBoot项目在启动的时候就会自动的加载这份儿配置文件，将文件当中所配置的自动配置类直接导入到Spring的IOC容器当中，在项目当中，我们要想使用该Bean对象，直接进行依赖注入即可。

3.2.4.3 自定义starter测试

阿里云OSS的starter我们刚才已经定义好

在test工程中引入阿里云starter依赖
- 通过依赖传递，会把autoconfigure依赖也引入了

<!-- 引入阿里云OSS起步依赖-->
        <dependency>
            <groupId>com.gch</groupId>
            <artifactId>aliyun-oss-spring-boot-starter</artifactId>
            <version>0.0.1-SNAPSHOT</version>
        </dependency>

SpringBoot原理

1. 配置的优先级

配置文件优先级排名（从高到低）：

结论-优先级： 命令行参数 > 系统属性参数 > properties参数 > yml参数 > yaml参数

注意事项：

2. 多环境配置

3. Spring IOC容器中Bean的管理

3.1 获取Bean

注意:声明一个bean对象如果没有指定名称,默认类名首字母小写

问题：输出的bean对象地址值是一样的，说明IOC容器当中的bean对象有几个？

3.2 Bean作用域

3.2.1 Bean的作用域的配置

3.2.2 @Lazy注解

注意事项：

注意事项：

3.3 Bean的生命周期相关的两个注解

@PostConstruct

@PreDestroy

注意：

3.4 关于第三方bean的声明

那么我们应该怎样使用并定义第三方的bean呢？

注意事项 ：

@Component及衍生注解与@Bean注解使用场景？

关于Bean大家只需要保持一个原则：

4. SpringBoot原理

SpringBoot框架的两大核心：

3.1 起步依赖

什么是Starter？

Maven中的Optional可选依赖

3.2 自动配置

3.2.1 概述

注意：区分自动配置和自动装配

术语："配置类"，英文Configuration Class：

3.2.2 常见方案

3.2.2.1 概述

3.2.2.2 方案一

3.2.2.3 方案二

3.2.3 原理分析

3.2.3.1 源码跟踪

自动配置源码小结

3.2.3.2 @Conditional

@Conditional注解：

最后再梳理一下自动配置原理：

Spring Boot启动流程简化版：

3.2.4 案例

3.2.4.1 自定义starter分析

3.2.4.2 自定义starter实现

3.2.4.3 自定义starter测试

结论-优先级：命令行参数 > 系统属性参数 > properties参数 > yml参数 > yaml参数

注意事项：