Java SPI介绍

SPI

Java SPI : Service Provider Interface

是Java平台提供的一种机制，用于动态的加载和扩展功能的机制，它为框架和库提供了一种松耦合的扩展方式，核心是解耦。

例如JDBC驱动，日志框架，等应用，它为开发者提供了一种灵活的，可插拔的扩展机制，使得使用更加方便灵活，更改配置即可。

SPI整体机制图

SPI和API区别？

API 是用于定义和提供功能接口的一种方式；

而 SPI 是一种用于动态加载和扩展功能的机制。

SPI接口位于调用方包中：

接口位于调用方中，而实现在独立的包之中。

API接口位于实现方包中：

接口和实现均位于一个包中。

SPI 代码实现

1. 先创建一个接口

   package com.junfeng.spi;
   
   public interface Logger {
       void log(String msg);
   }
   
   

2. 实现接口

   console实现:

   package com.junfeng.spi;
   
   public class ConsoleLogger implements Logger {
       @Override
       public void log(String msg) {
           System.out.println("console sys logger:" + msg);
       }
   }
   
   

   file实现:

   package com.junfeng.spi;
   
   public class FileLogger implements Logger {
       @Override
       public void log(String msg) {
           System.out.println("file sys logger:" + msg);
       }
   }
   

3. 配置

   创建配置文件：为每个提供者创建一个配置文件，指定提供者的实现类名。

   在 META-INF/services/ 目录下创建文件 com.junfeng.spi.Logger，其中 com.junfeng.spi.Logger 是 Logger 接口的完全限定名，内容如下：

   com.junfeng.spi.ConsoleLogger
   com.junfeng.spi.FileLogger
   

4. 调用

   在这个示例中，ServiceLoader.load(Logger.class) 用于加载 Logger 接口的实现提供者，然后通过遍历加载的提供者，调用其 log 方法输出日志。

package com.junfeng.spi;

import java.util.ServiceLoader;

public class Test {

    public static void main(String[] args) {
        // 加载 Logger 接口的实现
        ServiceLoader<Logger> loggerLoader = ServiceLoader.load(Logger.class);
        // 遍历并使用实现提供者
        for (Logger logger : loggerLoader) {
            logger.log("hello");
        }
    }
}

原理

SPI 机制的底层原理是基于 Java 的标准类加载和反射机制。

有兴趣的看下Class.forName，里面使用到了反射方法Class.forName()加载类对象。

SPI优缺点

优点：

1. 松耦合和可扩展性：SPI 机制可以实现插件化的架构，将接口和实现彻底解耦，使得框架和应用程序更易于扩展和维护。通过添加新的实现提供者，可以在不修改代码的情况下扩展功能。
2. 动态加载和发现：SPI 允许在运行时动态加载实现提供者，使得框架能够根据配置文件自动发现和加载新的功能模块，从而实现了更大的灵活性。
3. 无需修改源代码：使用 SPI，开发人员可以将接口和实现分开，避免了在框架源代码中引入大量的条件判断，使得框架更加清晰和可维护。
4. 分离关注点：SPI 机制允许框架关注于核心功能，而将特定的实现细节留给实现提供者来处理，提高了代码的模块化和可理解性。

缺点：

1. 没有版本管理：SPI 机制本身不提供强大的版本控制机制，当不同版本的提供者实现并存时，可能会导致不可预测的行为。
2. 没有依赖管理：SPI 机制不具备管理依赖关系的能力，这意味着实现提供者在开发时需要确保依赖的库和版本是正确的。
3. 不适用于复杂多实现场景：SPI 适用于一对一的接口和实现关系，当存在复杂的多实现关系时，可能需要更高级的机制来管理和调度实现。
4. 运行时的性能开销：SPI 机制在运行时需要进行实现提供者的查找和加载，这会带来一些性能开销，尤其在大规模应用中可能会有所感知。
5. 不适合对稳定性要求较高的场景：SPI 机制的动态性可能会增加系统的复杂性，对于对稳定性要求较高的场景，需要更严格的测试和控制。