Java SPI在数据库驱动、SpringBoot自动装配中的应用

文章目录

1. 初识SPI
- 1.1 SPI的作用
- 1.2 SPI的工作原理
- 1.3 SPI的三个组件：Service、Service Provider、ServiceLoader
- 1.4 SPI使用场景
- 1.5 具体的SPI 源码分析（SPI的核心就是ServiceLoader.load()方法）
- 1.6 SPI 的优缺点
2. API、SPI、JNDI释义
3. SPI应用举例1：加载数据库驱动
- 3.1 Jdbc连接数据库示例代码
- 3.2 为什么获取连接前不用获取驱动了，是怎么获取到驱动的？
- - 3.2.1 程序开始获取连接
  - 3.2.2 DriverManager开始初始化驱动
  - 3.2.3 调用ServiceLoader来发现驱动，使用类加载器加载jar中META-INF/services/下资源文件中的实现类
  - - 3.2.3.1 oracle驱动具体实现类oracle.jdbc.OracleDriver，实现了java.sql.Driver
    - 3.2.3.2 mysql驱动具体实现类com.mysql.cj.jdbc.Driver，实现了java.sql.Driver
4. SPI应用举例2：SpringBoot自动装配
- 4.1 SpringBoot自动装配借鉴了SPI思想
- 4.2 Spring Boot 的自动装配（Auto-configuration）原理
5. Spring Boot Starter
6. 只有Spring Boot Starter有spring.factories文件吗

1. 初识SPI

Java SPI（Service Provider Interface）是Java提供的一种服务发现机制，允许第三方为某个接口或类库提供实现。SPI的核心在于java.util.ServiceLoader类，它允许在运行时查找和加载服务的实现。
一般理解是：专门提供给服务提供者或者扩展框架功能的开发者去使用的一个接口。

1.1 SPI的作用

SPI 的合作作用：解耦。
SPI 将服务接口和具体的服务实现分离开来，将服务调用方和服务实现者解耦，能够提升程序的扩展性、可维护性。修改或者替换服务实现并不需要修改调用方。
很多框架都使用了 Java 的 SPI 机制，比如：Spring 框架、数据库加载驱动、日志接口、以及Dubbo 的扩展实现等。

1.2 SPI的工作原理

定义接口：首先，在API中定义一个接口或者抽象类作为服务接口，所有服务提供者都需要按照这个接口来实现其功能。
创建配置文件：在jar包的META-INF/services目录下，创建一个以服务接口全限定名命名的文本文件，该文件中每一行写入一个实现了服务接口的具体类的全限定名。
服务发现与加载：当应用程序需要使用某项服务时，通过ServiceLoader.load(ServiceInterface.class)方法动态加载服务接口的所有实现类，并将其实例化。这样，系统就可以在运行时根据不同的配置加载不同的服务实现。
SPI常用于框架扩展、插件机制以及模块间解耦等场景，使得系统的可扩展性和灵活性大大增强。例如，数据库驱动的加载就是Java SPI的一个典型应用案例。

对于 Java 原生 SPI，只需要满足下面几个条件：

定义服务的通用接口，针对通用的服务接口，提供具体的实现类
在 src/main/resources/META-INF/services 或者 jar包的 META-INF/services/ 目录中，新建一个文件，文件名为接口的全名。文件内容为该接口的具体实现类的全名
将 spi 所在 jar 放在主程序的 classpath 中
服务调用方用java.util.ServiceLoader，用服务接口为参数，去动态加载具体的实现类到JVM中，然后就可以正常使用服务了

1.3 SPI的三个组件：Service、Service Provider、ServiceLoader

SPI其实是一种思想：约定大于配置

简单来说就是：jdk提供一个公共API，具体的实现由具体的应用程序自己完成，并约定一套规则来让java的类加载机制发现实现类所在位置

通过这个约定，就不需要把服务放在代码中了，通过模块被装配的时候就可以发现服务类了

Service：是一个公开的接口或抽象类，定义了一个抽象的功能模块（文件名称）
Service Provider：是Service的实现类（文件内容）
ServiceLoader（java.util包下）：是SPI机制中的核心组件，负责在运行时发现并加载Service Provider

在这里插入图片描述

1.4 SPI使用场景

很多开源第三方jar包都有基于SPI的实现，在jar包META-INF/services中都有相关配置文件。

如下几个常见的场景：

JDBC加载不同类型的数据库驱动
Slf4j日志框架
Dubbo框架

看看 Dubbo 的扩展实现，就知道 SPI 机制用的多么广泛:
在这里插入图片描述

1.5 具体的SPI 源码分析（SPI的核心就是ServiceLoader.load()方法）

调用ServiceLoader.load()，创建一个ServiceLoader实例对象
创建LazyIterator实例对象lookupIterator
通过lookupIterator.hasNextService()方法读取固定目录META-INF/services/下面service全限定名文件，放在Enumeration对象configs中
解析configs得到迭代器对象Iterator pending
通过lookupIterator.nextService()方法初始化读取到的实现类，通过Class.forName()初始化

从上面的步骤可以总结以下两点

实现类工程必须创建定目录META-INF/services/，并创建service全限定名文件，文件内容是实现类全限定名
实现类必须有一个无参构造函数

1.6 SPI 的优缺点

优点

通过 SPI 机制能够大大地提高接口设计的灵活性，可以另起jar实现，不必写在一个模块中

缺点

需要遍历加载所有的实现类，不能做到按需加载，这样效率还是相对较低的。
当多个 ServiceLoader 同时 load 时，会有并发问题。
SPI 缺少实例的维护，作用域没有定义singleton和prototype的定义，不利于用户自由定制。
ServiceLoader不像 Spring，只能一次获取所有的接口实例，不支持排序，随着新的实例加入，会出现排序不稳定的情况，作用域没有定- 义singleton和prototype的定义，不利于用户自由定制

2. API、SPI、JNDI释义

API（Application Programming Interface）就是接口，比如java.util.List 是一个接口，是一个API
SPI（Service Provider Interface）是一种思想
JNDI（Java Naming and Directory Interface）
- 是Java平台中的一种标准服务，它提供了一组API，允许Java应用程序查找和访问命名以及目录服务。这个接口的设计目的是统一不同命名服务和目录服务的访问方式，使得开发人员无需关注具体的底层实现细节，就能在分布式环境中查找、绑定和管理资源。
- 通过JNDI，开发者可以：
  - 命名：将对象与名称关联起来存储，并可以通过名称来获取这些对象。
  - 目录服务：除了基本的命名功能外，还支持属性查询，即根据对象的属性信息进行检索。目录服务中的条目类似于文件系统中的文件，每个条目都有名称，并且可以携带多个属性。
- JNDI常用于以下场景：
  - 在Java EE应用服务器中，配置数据源（DataSource）、EJB引用、JMS队列和主题等资源，并通过统一的名字查找和使用它们。
    在企业级应用中，定位网络服务的位置或属性，例如LDAP（轻量级目录访问协议）目录服务中的用户账户信息。
    简而言之，JNDI是一个抽象层，它隐藏了各种各样的命名和目录服务的具体实现细节，为Java程序提供了统一、灵活且易于使用的编程接口。

3. SPI应用举例1：加载数据库驱动

依赖引用

<dependency>
    <groupId>com.oracle.database.jdbc</groupId>
    <artifactId>ojdbc8</artifactId>
    <version>21.9.0.0</version>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.23</version>
</dependency>

SPI是JDK内置的一种动态扩展点的实现。
简单来说，就是我们可以定义一个标准的接口，然后第三方的库里面可以实现这个接口。
那么，程序在运行的时候，会根据配置信息动态加载第三方实现的类，从而完成功能的动态扩展机制。

解释图1：
在这里插入图片描述

解释图2：
在这里插入图片描述

在Java里面，SPI机制有一个非常典型的实现案例，就是数据库驱动java.jdbc.Driver,JDK里面定义了数据库驱动类Driver，它是一个接口，JDK并没有提供实现。
具体的实现是由第三方数据库厂商来完成的。在程序运行的时候，会根据我们声明的驱动类型，来动态加载对应的扩展实现，从而完成数据库的连接。

除此之外，在很多开源框架里面都借鉴了Java SPI的思想，提供了自己的SPI框架，比如Dubbo定义了ExtensionLoader，实现功能的扩展。Spring提供了SpringFactoriesLoader，实现外部功能的集成。
当服务的提供者，提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。通过这个约定，就不需要把服务放在代码中了，通过模块被装配的时候就可以发现服务类了。

3.1 Jdbc连接数据库示例代码

有了SPI机制之后，Class.forName(“com.mysql.jdbc.Driver”);这条语句就不需要了，

java.util.ServiceLoader会负责到jar包的META-INF/services/java.sql.Driver中获取具体驱动实现类

import java.io.IOException;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

public class JdbcDriverManagerDemo {

    static final String MYSQL_JDBC_DRIVER = "com.mysql.cj.jdbc.Driver";
    private static final String MYSQL_URL = "jdbc:mysql://localhost:3306/lelele?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=UTC";
    private static final String USER = "root";
    private static final String PASSWORD = "admin123";


    public static void main(String[] args) {


        Connection conn = null;
        PreparedStatement ps = null;
        ResultSet rs = null;

        try {
            // 有了SPI机制之后，这条语句就不要了，
            // java.util.ServiceLoader会负责到jar包的META-INF/services/java.sql.Driver中获取具体驱动实现类

            // Class.forName("com.mysql.jdbc.Driver");
            conn = DriverManager.getConnection(MYSQL_URL, USER, PASSWORD);

            ps = conn.prepareStatement("select * from xin_stu_t_bak");
            rs = ps.executeQuery();

            while (rs.next()) {
                System.out.println(rs.getInt("id"));
            }

            // 处理查询结果
            while (rs.next()) {
                int id = rs.getInt("id");
                String name = rs.getString("name");
                System.out.println("ID: " + id + ", Name: " + name);
            }

        } catch (SQLException se) {
            // 处理SQL错误
            se.printStackTrace();
        } catch (Exception e) {
            // 处理其他异常
            e.printStackTrace();
        } finally {
            // 关闭资源，确保在任何情况下都能正确关闭
            try {
                if (rs != null)
                    rs.close();
                if (ps != null)
                    ps.close();
                if (conn != null)
                    conn.close();
            } catch (SQLException se2) {
                se2.printStackTrace();
            }
        }

        System.out.println("end!");
    }
}

3.2 为什么获取连接前不用获取驱动了，是怎么获取到驱动的？

源码分析参照本文章1.5节具体的SPI 源码分析（SPI的核心就是ServiceLoader.load()方法）

下面是获取连接对象代码调试中的一些断点截图

3.2.1 程序开始获取连接

在这里插入图片描述

3.2.2 DriverManager开始初始化驱动

在这里插入图片描述

3.2.3 调用ServiceLoader来发现驱动，使用类加载器加载jar中META-INF/services/下资源文件中的实现类

使用线程上下文类加载器(ContextClassLoader)加载

- 如果不做任何的设置，Java应用的线程的上下文类加载器默认就是AppClassLoader。在核心类库使用SPI接口时，传递的类加载器使用线程上下文类加载器，就可以成功的加载到SPI实现的类。线程上下文类加载器在很多SPI的实现中都会用到。

- 通常我们可以通过Thread.currentThread().getClassLoader()和Thread.currentThread().getContextClassLoader()获取线程上下文类加载器。

在这里插入图片描述

3.2.3.1 oracle驱动具体实现类oracle.jdbc.OracleDriver，实现了java.sql.Driver

在这里插入图片描述

3.2.3.2 mysql驱动具体实现类com.mysql.cj.jdbc.Driver，实现了java.sql.Driver

在这里插入图片描述

4. SPI应用举例2：SpringBoot自动装配

4.1 SpringBoot自动装配借鉴了SPI思想

Spring Factories自动装配借用了SPI机制，区别如图：

在这里插入图片描述

Spring Boot的自动装配机制确实与SPI（Service Provider Interface）有关联，但并不是直接使用Java标准SPI来实现自动装配。Spring Boot借鉴了SPI的思想，在其内部设计了一套更加灵活和强大的自动配置体系。
在Spring Boot中，META-INF/spring.factories文件的使用方式类似于SPI的服务提供者配置文件(META-INF/services/下资源文件)，它允许jar包声明自己提供的自动配置类。这些自动配置类通过条件注解（如@ConditionalOnClass、@ConditionalOnBean等）来检查应用环境并决定是否生效，从而实现了根据项目依赖和运行时环境进行自动装配的功能。
因此，虽然Spring Boot没有完全采用Java SPI的标准流程，但其自动装配过程中对第三方库和服务的发现和加载机制受到了SPI思想的启发，并在此基础上进行了扩展和创新。

在这里插入图片描述

另：

META-IF/spring.factories是在Maven引入的Jar包中，每一个Jar都有自己META-IF/spring.factories，所以SpringBoot是去每一个Jar包里面寻找META-IF/spring.factories，而不是我的项目中存在META-IF/spring.factories（当然也可以存在，但是我项目的META-IF/spring.factories肯定没有类似以下这些东西）

在这里插入图片描述

4.2 Spring Boot 的自动装配（Auto-configuration）原理

@SpringBootApplication注解作用图

在这里插入图片描述

好处：简化了配置

Springboot的SPI机制是怎么实现的？

程序启动，注册配置类处理器
Spring刷新上下文，执行配置类处理器
扫描spring.factories将得到的BeanDefinition注册到容器
spring实例化/初始化这些BeanDefinition

Spring Boot 的自动装配（Auto-configuration）原理（上面也是）

启动类与@SpringBootApplication注解：
- Spring Boot应用通常包含一个主入口类，上面会标注@SpringBootApplication注解。
- 这个注解包含了@Configuration、@EnableAutoConfiguration和@ComponentScan三个注解
- 其中@EnableAutoConfiguration是开启自动装配的关键。
@EnableAutoConfiguration：
- @EnableAutoConfiguration注解指示Spring Boot根据项目的classpath和已存在的Bean来自动配置应用程序。
- 它会扫描项目依赖中所有jar包的META-INF/spring.factories文件，这些文件定义了哪些自动配置类应该被应用到当前项目中。
spring.factories中的自动配置类：
- 各个Spring Boot Starter模块在它们的jar包里都提供了一个spring.factories文件
- 该文件中列出了一系列org.springframework.boot.autoconfigure.EnableAutoConfiguration对应的实现类全名。
条件化装配：
- 自动配置类本身使用了Spring Boot提供的条件化装配机制，例如@ConditionalOnClass、@ConditionalOnMissingBean等注解。这意味着只有当满足特定条件时（如类路径中有某个类、没有用户自定义的同类型Bean等），才会实例化并注册相应的自动配置Bean。
覆盖默认配置：
- 如果开发者想要自定义某部分配置或者完全禁用某个自动配置，可以通过创建自己的配置类或在application.properties/application.yml中设置属性值来实现。Spring Boot会优先考虑用户自己定义的Bean或属性配置，从而实现了灵活的扩展和配置覆盖。
自定义自动配置：
- 开发者还可以编写自己的自动配置类，通过添加@Configuration注解，并利用条件装配注解来自定义特定场景下的自动化配置逻辑。

另：META-INF下另一个文件MANIFEST.MF的作用

MANIFEST.MF 是Java应用程序和JAR文件中用于存储元数据（metadata）的一个重要文件。它位于JAR文件的META-INF目录下，包含了关于该JAR包及其组件的重要信息。
MANIFEST.MF是Java应用打包和部署过程中不可或缺的一部分，为Java虚拟机（JVM）提供了有关如何加载和执行JAR内容的关键指导信息。

在JAR文件中，MANIFEST.MF 文件常见的用途包括：

Main-Class声明：对于可执行的JAR文件（也称为Runnable JAR或Self-executable JAR），需要在MANIFEST.MF文件中指定一个主类（Main-Class）。例如：
```
Main-Class: com.example.Main
```
这样，用户可以直接通过命令行 java -jar myapp.jar 来运行这个JAR程序。
Class-Path声明：用于定义当前JAR文件依赖的其他外部JAR文件的路径。例如：
```
Class-Path: lib/library.jar lib/anotherlibrary.jar
```
这样，当运行此JAR时，Java会自动加载指定路径下的库。
Sealed指示：可以用来表示JAR是否被密封（sealed），即所有包内的类都必须来自同一个代码源，以增强安全性。
签名信息：如果JAR文件被数字签名，那么相关的签名证书、签名者信息等也会记录在MANIFEST.MF中。
服务提供者信息：在实现Java SPI（Service Provider Interface）时，MANIFEST.MF也可以包含ServiceProvider-Impl条目，列出实现了某个接口的服务提供者的全限定类名。
OSGi Bundle信息：在OSGi框架中，每个Bundle都有自己的MANIFEST.MF文件，其中包含了Bundle的标识符、版本、导入导出的包、激活器等重要信息。

在这里插入图片描述

5. Spring Boot Starter

在这里插入图片描述

Spring Boot Starter 是 Spring Boot 框架中的一种模块化设计，旨在简化项目的初始化和依赖管理。它们是一组预配置的依赖项集合，每个Starter都针对特定的功能场景，例如数据访问、Web服务、安全控制等。
Spring Boot Starter通过预先集成并配置好了一系列功能组件，为开发者快速搭建应用提供了极大便利。
使用Spring Boot Starter的主要优点包括：

统一入口：只需要在Maven或Gradle构建文件中引入一个Starter依赖，就可以自动获得一组相关的库以及对应的默认配置。
约定优于配置：Starter包含了基于最佳实践的默认配置，极大地减少了开发者在项目启动阶段需要编写的配置代码量。
易用性与一致性：无论开发何种功能的应用程序，都可以遵循相同的模式来引入依赖，使得团队成员易于理解和操作。
减少版本冲突：由于Starter中的所有依赖版本都已经协调一致，因此可以避免不同组件之间的版本不兼容问题。

例如，spring-boot-starter-web 包含了开发Web应用程序所需的所有基本依赖，如Spring MVC、Tomcat服务器等；而 spring-boot-starter-data-jpa 则包含了使用JPA进行数据库持久化的相关依赖。

6. 只有Spring Boot Starter有spring.factories文件吗

并非只有Spring Boot Starter才有spring.factories文件。spring.factories 文件是Spring Boot框架为了实现自动配置（Auto-Configuration）和SPI（Service Provider Interface）机制而使用的一种约定。虽然它通常与Spring Boot Starter一起使用，但并非Spring Boot Starter特有的。
在任何Java项目中，只要符合Spring Boot的自动装配规则，都可以创建自己的META-INF/spring.factories文件来声明自定义的自动配置类或者其他扩展点。这意味着即使不是官方提供的Spring Boot Starter模块，开发者也可以编写自己的模块，并在其jar包中包含spring.factories文件来提供额外的自动配置服务。
所以，spring.factories文件不仅限于Spring Boot Starter，而是所有遵循Spring Boot规范并希望通过这种方式进行扩展的模块都可能包含的一个核心配置文件。

引用1

引用2

引用3