Java SPI的原理和实践

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: Java SPI的原理和实践

在Java中,我们经常会提到面向接口编程,这样减少了模块之间的耦合,更加灵活。

在一个项目中我们也通常将接口和实现类放在一起,但是如果哪天我们要替换其它的实现类,或者是修改实现类,涉及到实现类的代码也要相应地修改。

能不能这样:在调用服务的时候,我们只调用接口,不用关心实现类呢?无论我们怎么切换实现类,调用接口的部分代码都能正常运行?

当然是可以的,Java SPI (Service Provider Interface)就提供了这样的机制。

Java SPI机制中,我们不再是手动指定接口和实现类的关系,而是让接口去寻找可用的实现类

事实上,我们经常使用的Spring框架、日志接口等等,都是使用了SPI机制实现了扩展。

1,SPIAPI

在说起SPI之前,我们还是先看一下APIAPI我们已经很熟悉了,和SPI都可以被称作接口

只不过API功能的实现,以及接口的定义全部是接口的实现者提供的,调用者只需要调用接口即可:

image.png

不过SPI就不一样了,在SPI机制中,调用者仍然是调用接口,但是这个接口是独立存在的,并且可以由不同的实现者实现

image.png

也就是说,这里接口只是一个标准,并且提供接口的那一方并不一定回去实现接口,而是根据接口的定义,由更多的第三方实现。

这个接口可以由一个甚至是多个实现者去实现。也因此,调用者在调用接口时,可能还需要指定一下使用哪个实现者的实现类

实现者也叫做服务提供者

事实上,我们日常生活中经常使用的U盘也很类似SPI机制,U盘使用的是USB接口,USB接口仅仅是一个规范(接口),但是发明USB接口的公司并没有去生产U盘,而是由不同的U盘厂商例如金士顿、闪迪(实现者)等等去根据这个规范生产U盘,然后我们就可以去选择自己喜欢的牌子(选择实现者)购买U盘,不过平时无论使用什么牌子的U盘,我们只需要插入到电脑的USB接口(调用接口)即可使用,而不用关心不同的厂商是怎么实现USB接口的功能的。

可见,SPI机制将实现者和接口再次解耦合了,使得接口更加易于扩展。

事实上,我们常常用的SLF4J就是一个Java的日志接口,但是它也仅仅是一个接口,所以被称作门面。而它的实现有LogbackLog4j等等,并且在切换实现的时候,我们只需要修改一下依赖配置即可,代码并不需要任何变动,因为代码中也仅仅是调用了接口。

2,自己完成一个SPI

那么现在,我们也来以一个最简单的日志接口为例,实现自己的SPI

(1) 定义SPI接口

先新建一个空的Maven项目log-interface,然后在里面创建一个日志接口,声明日志接口具备的方法(功能):

package com.gitee.swsk33.loginterface.spi;

/**
 * 定义日志接口
 */
public interface Logger {
   

    /**
     * INFO级别日志方法
     *
     * @param message 日志打印消息
     */
    void info(String message);

    /**
     * DEBUG级别日志方法
     *
     * @param message 日志打印消息
     */
    void debug(String message);

}

这样,我们便定义了这么一个日志接口,并声明日志接口需要有infodebug这两个日志功能。

然后就是编写服务类,这个服务类是这里最为重要的地方,它的作用是扫描所有实现了Logger接口的实现类并加载进来,然后供调用者去调用

先看代码:

package com.gitee.swsk33.loginterface.service;

import com.gitee.swsk33.loginterface.spi.Logger;

import java.util.ArrayList;
import java.util.List;
import java.util.ServiceLoader;

/**
 * 服务,用于加载所有服务使用者的实现类,以及供外部调用
 * 该类为一个单例
 */
public class LoggerService {
   

    /**
     * 该类唯一单例
     */
    private static final LoggerService LOGGER = new LoggerService();

    /**
     * 默认的Logger实现类
     */
    private final Logger defaultLogger;

    /**
     * 所有的Logger实现类列表
     */
    private final List<Logger> allLoggers = new ArrayList<>();

    /**
     * 私有化构造器
     */
    private LoggerService() {
   
        // 加载全部Logger接口的实现类
        ServiceLoader<Logger> loader = ServiceLoader.load(Logger.class);
        // 将实现类放入我们的Logger实现类列表
        for (Logger logger : loader) {
   
            allLoggers.add(logger);
        }
        // 这里取出第一个作为默认实现类
        if (!allLoggers.isEmpty()) {
   
            defaultLogger = allLoggers.get(0);
        } else {
   
            defaultLogger = null;
        }
        System.out.println("加载到" + allLoggers.size() + "个服务实现!");
    }

    /**
     * 获取该服务类的唯一单例
     *
     * @return 该服务类的唯一单例
     */
    public static LoggerService getInstance() {
   
        return LOGGER;
    }

    /**
     * 调用默认的实现类的info日志打印方法
     *
     * @param message 消息
     */
    public void info(String message) {
   
        if (defaultLogger == null) {
   
            System.err.println("没有找到实现了Logger接口的类!");
            return;
        }
        defaultLogger.info(message);
    }

    /**
     * 调用默认的实现类的debug日志打印方法
     *
     * @param message 消息
     */
    public void debug(String message) {
   
        if (defaultLogger == null) {
   
            System.err.println("没有找到实现了Logger接口的类!");
            return;
        }
        defaultLogger.debug(message);
    }

}

首先这个类是一个单例的类,在构造器中,我们使用ServiceLoader这个类来将实现了Logger接口的所有类都扫描进来,并存入我们的实现类列表,然后我们取出列表中的第一个作为默认实现。

在下面我们定义了infodebug来完成对接口的默认实现类的调用。

最后,在项目目录下执行mvn install命令将其安装至本地Maven仓库,以便后续服务提供者引入并实现。

(2) 完成一个接口的实现

现在再新建一个空的Maven项目logservice-one,并引入上面接口项目为依赖:

image.png

然后编写实现类:

package com.gitee.swsk33.logserviceone.service;

import com.gitee.swsk33.loginterface.spi.Logger;

/**
 * Logger SPI的实现类
 */
public class LogOne implements Logger {
   

    @Override
    public void info(String s) {
   
        System.out.println("[LogOne INFO] " + s);
    }

    @Override
    public void debug(String s) {
   
        System.out.println("[LogOne DEBUG] " + s);
    }

}

然后在resources目录下创建目录META-INF/services,这个目录中是用于声明该服务实现中有哪些实现类实现了什么接口

在这个目录下我们新建一个文件名为com.gitee.swsk33.loginterface.spi.Logger,文件中的内容为:

com.gitee.swsk33.logserviceone.service.LogOne

可见,该目录下文件名要实现的接口的全限定类名(包名 + 类名),而文件中内容实现了该接口的实现类的全限定类名

大家参考这里的文件名及其中的内容,与我们上述的接口全限定类名、实现类全限定类名对比一下就知道了!

如果说这个项目中有多个类实现了Logger接口,那么我们都需要在文件中声明,一行一个实现类的全限定类名。

最终整个项目结构如下:

image.png

同样地,最后记得在项目目录下执行mvn install命令将其安装至本地Maven仓库,以便调用者调用。

(3) 测试接口

这里再新建一个Maven空项目log-test,作为接口的调用者,在依赖中引入实现者

image.png

然后创建一个主类调用一下接口试试:

package com.gitee.swsk33.logtest;

import com.gitee.swsk33.loginterface.service.LoggerService;

public class Main {
   

    private static final LoggerService LOGGER = LoggerService.getInstance();

    public static void main(String[] args) {
   
        LOGGER.info("测试info消息");
        LOGGER.debug("测试debug消息");
    }

}

结果:

image.png

可见,我们成功地调用了Logger接口中的方法。

通常调用者的依赖中可能会同时引入SPI接口依赖和服务提供者(实现)的依赖,这样也没问题,不过通常服务提供者本身就依赖于SPI接口,因此只引入服务提供者依赖,也会间接地引入SPI接口依赖,不影响我们调用SPI接口。

我们这里只有一个服务提供者logservice-one,如果说还有logservice-two等等多个服务提供者,我们只需要在依赖中更换一下即可,代码完全不需要改变。

也可见调用者在调用接口的时候,只需要关注接口就行了,不需要关心实现类。

3,再看ServiceLoader

可见在SPI接口中,我们使用ServiceLoader完成了对所有实现了Logger接口的类的扫描和加载,那么具体的过程是什么样的呢?

如果大家去查看这个类的源码,可以发现它实现了Iterable接口,这也说明我们可以通过迭代的方式去完成多个实现类的切换。

然后在其源码中,有这么一个常量定义:

static final String PREFIX = "META-INF/services/";

这就说明,ServiceLoader会去扫描服务提供者的classpath路径下的META-INF/services目录,来扫描哪些类实现了指定接口,而其静态方法load的参数,正是指定了被实现的接口。也因此我们要在服务提供者的项目的resources目录下创建这个目录并申明接口和对应实现类的全限定类名。

在Maven项目中,resources目录就对应的是classpath的根目录。

简而言之,ServiceLoader加载实现类的过程如下:

  • 先是调用load方法并指定要扫描的接口
  • 然后扫描项目中META-INF/services目录,这包括调用者项目以及它所引入的所有依赖包中的META-INF/services目录下的声明
  • 扫描到所有实现类后,根据其类名,先判断是否跟SPI接口为同一类型,如果是则利用反射的方式将所有实现类实例化,加载进内存,并返回所有实现类的实例列表

可见,这就是JDK中SPI机制加载服务的大致过程,事实上,现在很多框架也利用SPI机制实现了灵活地扩展。

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
相关文章
|
2月前
|
SQL 缓存 安全
深度理解 Java 内存模型:从并发基石到实践应用
本文深入解析 Java 内存模型(JMM),涵盖其在并发编程中的核心作用与实践应用。内容包括 JMM 解决的可见性、原子性和有序性问题,线程与内存的交互机制,volatile、synchronized 和 happens-before 等关键机制的使用,以及在单例模式、线程通信等场景中的实战案例。同时,还介绍了常见并发 Bug 的排查与解决方案,帮助开发者写出高效、线程安全的 Java 程序。
156 0
|
2月前
|
存储 搜索推荐 算法
Java 大视界 -- Java 大数据在智慧文旅旅游线路规划与游客流量均衡调控中的应用实践(196)
本实践案例深入探讨了Java大数据技术在智慧文旅中的创新应用,聚焦旅游线路规划与游客流量调控难题。通过整合多源数据、构建用户画像、开发个性化推荐算法及流量预测模型,实现了旅游线路的精准推荐与流量的科学调控。在某旅游城市的落地实践中,游客满意度显著提升,景区流量分布更加均衡,充分展现了Java大数据技术在推动文旅产业智能化升级中的核心价值与广阔前景。
|
2月前
|
监控 Java API
现代 Java IO 高性能实践从原理到落地的高效实现路径与实战指南
本文深入解析现代Java高性能IO实践,涵盖异步非阻塞IO、操作系统优化、大文件处理、响应式网络编程与数据库访问,结合Netty、Reactor等技术落地高并发应用,助力构建高效可扩展的IO系统。
82 0
|
2月前
|
并行计算 Java API
Java List 集合结合 Java 17 新特性与现代开发实践的深度解析及实战指南 Java List 集合
本文深入解析Java 17中List集合的现代用法,结合函数式编程、Stream API、密封类、模式匹配等新特性,通过实操案例讲解数据处理、并行计算、响应式编程等场景下的高级应用,帮助开发者提升集合操作效率与代码质量。
134 1
|
2月前
|
存储 Java 大数据
Java 大视界 —— 基于 Java 的大数据隐私保护在金融客户信息管理中的实践与挑战(178)
本文探讨了基于 Java 的大数据隐私保护技术在金融客户信息管理中的应用与挑战。随着金融行业数字化转型加速,客户信息的安全性愈发重要。文章详细分析了数据加密、脱敏、访问控制、区块链及联邦学习等关键技术,并结合实际案例展示了其在金融机构中的应用效果,为金融科技从业者提供了宝贵的实践经验与技术参考。
|
2月前
|
存储 缓存 安全
深入讲解 Java 并发编程核心原理与应用案例
本教程全面讲解Java并发编程,涵盖并发基础、线程安全、同步机制、并发工具类、线程池及实际应用案例,助你掌握多线程开发核心技术,提升程序性能与响应能力。
110 0
|
10天前
|
数据采集 存储 弹性计算
高并发Java爬虫的瓶颈分析与动态线程优化方案
高并发Java爬虫的瓶颈分析与动态线程优化方案
Java 数据库 Spring
46 0
|
22天前
|
算法 Java
Java多线程编程:实现线程间数据共享机制
以上就是Java中几种主要处理多线程序列化资源以及协调各自独立运行但需相互配合以完成任务threads 的技术手段与策略。正确应用上述技术将大大增强你程序稳定性与效率同时也降低bug出现率因此深刻理解每项技术背后理论至关重要.
56 16