浅析Java中的SPI原理

在面向对象的程序设计中,模块之间交互采用接口编程,通常情况下调用方不需要知道被调用方的内部实现细节,因为一旦涉及到了具体实现,如果需要换一种实现就需要修改代码,这违反了程序设计的"开闭原则"。所以我们一般有两种选择:一种是使用API(Application Programming Interface),另一种是SPI(Service Provider Interface),API通常被应用程序开发人员使用,而SPI通常被框架扩展人员使用。

在进入下面学习之前,我们先来再加深一下API和SPI这两个的印象:

API:由实现方制定接口标准并完成对接口的不同实现,这种模式服务接口从概念上更接近于实现方;

SPI:由调用方制定接口标准,实现方来针对接口提供不同的实现;从前半句话我们来看,SPI其实就是"为接口查找实现"的一种服务发现机制;这种模式,服务接口组织上位于调用方所在的包中,实现位于独立的包中。

API和SPI简略图示:

  

看完上面的简单图示,相信大家对API和SPI的区别有了一个大致的了解,现在我们使用SPI机制来实现我们一个简单的日志框架:

第一步,创建一个maven项目命名为spi-interface,定义一个SPI对外服务接口,用来后续提供给调用者使用;

package cn.com.wwh;
/**
 *
 * @FileName Logger.java
 * @version:1.0
 * @Description: 服务提供者接口
 * @author: wwh
 * @date: 2022年9月19日 上午10:31:53
 */
public interface Logger {

    /**
     *
     * @Description:(功能描述)
     * @param msg
     */
    public void info(String msg);

    /**
     *
     * @Description:(功能描述)
     * @param msg
     */
    public void debug(String msg);
}
package cn.com.wwh;

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

/**
 *
 * @FileName LoggerService.java
 * @version:1.0
 * @Description: 为服务的调用者提供特定的功能,是SPI的核心功能
 * @author: wwh
 * @date: 2022年9月19日 上午10:33:30
 */
public class LoggerService {

    private static final LoggerService INSTANCE = new LoggerService();

    private final Logger logger;                          

    private final List<Logger> loggers = new ArrayList<>();

    private LoggerService() {
     //ServiceLoader是实现SPI的核心类
        ServiceLoader<Logger> sl = ServiceLoader.load(Logger.class);
        Iterator<Logger> it = sl.iterator();
        while (it.hasNext()) {
            loggers.add(it.next());
        }

        if (!loggers.isEmpty()) {
            logger = loggers.get(0);
        } else {
            logger = null;
        }
    }

    /**
     * @Description:(功能描述)
     * @return
     */
    public static LoggerService getLoggerService() {
        return INSTANCE;
    }

    /**
     *
     * @Description:(功能描述)
     * @param msg
     */
    public void info(String msg) {
        if (logger == null) {
            System.err.println("在info方法中没有找到Logger的实现类...");
        } else {
            logger.info(msg);
        }
    }

    /**
     *
     * @Description:(功能描述)
     * @param msg
     */
    public void debug(String msg) {
        if (logger == null) {
            System.err.println("在debug方法中没有找到Logger的实现类...");
        } else {
            logger.info(msg);
        }
    }
}

将上面这个这个项目打成spi-interface.jar包。

第二步,新建一个maven项目并导入第一步中打出来的spi-interface.jar包,这个项目用来提供服务的实现,定义一个类,实现第一步中定义的cn.com.wwh.Logger接口,示例代码如下:

package cn.com.wwh;

import cn.com.pep.Logger;

/**
 *
 * @FileName Logback.java
 * @version:1.0
 * @Description: 服务接口的实现类
 * @author: wwh
 * @date: 2022年9月19日 上午10:50:31
 */
public class Logback implements Logger {

    @Override
    public void debug(String msg) {
        System.err.println("调用Logback的debug方法,输出的日志为:" + msg);
    }

    @Override
    public void info(String msg) {
        System.err.println("调用Logback的info方法,输出的日志为:" + msg);
    }

}

同时在当前项目的classpath路径下建立META-INF/services/文件夹(至于为什么这么建立目录,我们一会儿再解释),并且新建一个名称为cn.com.wwh.Logger内容为cn.com.wwh.Logback的文件,这一步是关键(具体作用后面再详细说明),然后将上面第二步这个这个项目打成spi-provider.jar包,供给之后使用,我目前使用的开发工具是Eclipse,目录结构如下图所示:

第三步,编写测试类,新建一个maven项目,命名为spi-test,导入前面两个步骤打的spi-interface.jar和spi-provider.jar这两个jar包,并编写测试代码,示例如下:

package cn.com.wwh;

import cn.com.pep.LoggerService;

/**
 *
 * @FileName SpiTest.java
 * @version:1.0
 * @Description:
 * @author: wwh
 * @date: 2022年9月19日 上午10:56:31
 */
public class SpiTest {

    public static void main(String[] args) {
        LoggerService logger = LoggerService.getLoggerService();
        logger.info("我是中国人");
        logger.debug("白菜多少钱一斤");
    }
}

有了SPI我们可以将服务和服务提供者轻松地解耦,假如将来的某一天我们需要将日志保存到数据库,或者通过网络发送,我们直接只需要替换针对服务接口的实现类即可,别的地方都不用修改,这更符合程序设计中的“开闭原则”。

SPI的大致原理是:应用启动的时候,扫描classpath下面的所有jar包,将jar包下的/META-INF/services/目录下的文件加载到内存中,进行一系列的解析(文件的名称是spi接口的全路径名称,文件内容应该是spi接口实现类的全路径名,可以用多个实现类,在文件中换行保存),之后判断当前类和当前接口是否是同一类型?结果为true,则通过反射生成指定类的实例对象,保存到一个map集合中,可以通过遍历或者迭代的方式拿出来使用。

SPI实质就是一个加载服务实现的工具,核心类是ServiceLoader,其实了解了SPI的原理,我们再接着探究JDK中的源码就没有那么费力了,下面我们开始源码分析吧。

ServiceLoader类是定义在java.util包下的,使用final定义禁止子类继承和修改,实现了Iterable接口,使得可以通过迭代或者遍历的方式获取SPI接口的不同实现。

从上面的我们所举的例子中,我们知道SPI的入口是ServiceLoader.load(Class<S> service)方法,我们来看看它都干了什么?   

上面的这4步总的来说,就是使用指定的类型和当前线程绑定的classLoader实例化了一个LazyIterator对象赋值给lookupIterator这个引用,并且清除了原来providers列表中缓存的服务的实现。接下来我们调用了ServiceLoader实例的iterator()方法获取了一个迭代器,代码如下:

public Iterator<S> iterator() {
        //通过匿名内部类方式提供了一个迭代器
        return new Iterator<S>() {
            //获取缓存的服务实现者的迭代器
            Iterator<Map.Entry<String, S>> knownProviders = providers.entrySet().iterator();

            //判断迭代器中是否还有元素
            public boolean hasNext() {
                //缓存的服务实现者的迭代器中已经没有元素了
                if (knownProviders.hasNext())
                    return true;
                return lookupIterator.hasNext();//判断延迟加载的迭代器中是否还有元素
            }

            //获取迭代其中的下一个元素
            public S next() {
                if (knownProviders.hasNext())
                    return knownProviders.next().getValue();
                return lookupIterator.next();//获取延迟加载的迭代器中的下一个元素
            }

            public void remove() {
                throw new UnsupportedOperationException();
            }
        };
   }

我们接着调用上步获取的迭代器it的hasNext()方法,因为我们在ServiceLoader.load()过程中其实是清除了providers列表中的缓存服务实现的,所以其实调用的是lookupIterator.hasNext()方法,如下:

public boolean hasNext() {
        if (nextName != null) {//存在下一个元素
            return true;
        }
        if (configs == null) {//配置文件为空
            try {
                String fullName = PREFIX + service.getName();//获取配置文件路径
                if (loader == null)
                    configs = ClassLoader.getSystemResources(fullName);
                else
                    configs = loader.getResources(fullName);//加载配置文件
            } catch (IOException x) {
                fail(service, "Error locating configuration files", x);
            }
        }
        //遍历配置文件内容
        while ((pending == null) || !pending.hasNext()) {
            if (!configs.hasMoreElements()) {
                return false;
            }
            pending = parse(service, configs.nextElement());//配置文件内容解析
        }
        nextName = pending.next();//获取服务实现类的全路径名
        return true;
    }

假如上部判断为true,紧接着我们又调用了迭代器it的next()方式,同理也调用的是lookupIterator.next()方法,源码如下:

public S next() {
        if (!hasNext()) {
            throw new NoSuchElementException();
        }
        String cn = nextName;//文件中保存的服务接口实现类的全路径名
        nextName = null;
        Class<?> c = null;
        try {
            //获取全限定名的Class对象
            c = Class.forName(cn, false, loader);
        } catch (ClassNotFoundException x) {
            fail(service, "Provider " + cn + " not found");
        }
            //判断实现类和服务接口是否是同一类型
        if (!service.isAssignableFrom(c)) {
            fail(service, "Provider " + cn + " not a subtype");
        }
        try {
            //通过反射生成服务接口的实现类,并判断这个实例是否是接口的实现
            S p = service.cast(c.newInstance());
            //将服务接口的实现缓存起来,并返回
            providers.put(cn, p);
            return p;
        } catch (Throwable x) {
            fail(service, "Provider " + cn + " could not be instantiated", x);
        }
        throw new Error(); // This cannot happen
    }

其实spi实现的主要流程是:扫描classpath路径下的所有jar包下的/META-INF/services/目录(即我们需要将服务接口的具体实现类暴露在这个目录下,之前我们提到需要在实现类的classpath下面建立一个/META-INF/services/文件夹就是这个原因。),找到对应的文件,读取这个文件名找到对应的SPI接口,然后通过InputStream流将文件内容读出来,获取到实现类的全路径名,并得到这个全路径名所表示的Class对象,判断其与服务接口是否是同一类型,然后通过反射生成服务接口的实现,并保存在providers列表中,供给后续的使用。

SPI这种设计方式为我们的应用扩展提供了极大的便利,但是它的短板也是显而易见的,Java SPI 在查找扩展实现类的时候遍历 SPI 的配置文件并且将实现类全部实例化,假设一个实现类初始化过程比较消耗资源且耗时,但是你的代码里面又用不上它,这就产生了资源的浪费。所以说 Java SPI 无法按需加载实现类。

另外,SPI 机制在很多框架中都有应用:slf4j日志框架、Spring 框架的基本原理也是类似的反射。还有 Dubbo 框架提供同样的 SPI 扩展机制,只不过 Dubbo 和 spring 框架中的 SPI 机制具体实现方式跟咱们今天学得这个有些细微的区别(Dubbo可以实现按需加载实现类),不过整体的原理都是一致的,我们今天先对SPI有个简单的了解,相信有了今天的基础理解剩下的那几个也不是什么难事。

好了,今天就到这儿了,文章中有说的不对的地方还请各位大佬批评指正,一起学习,共同进步,谢谢。

到此这篇关于浅析Java中的SPI原理的文章就介绍到这了,更多相关Java SPI原理内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Java和Dubbo的SPI机制原理解析

    SPI: 简单理解就是,你一个接口有多种实现,然后在代码运行时候,具体选用那个实现,这时候我们就可以通过一些特定的方式来告诉程序寻用那个实现类,这就是SPI. JAVA的SPI 全称为 Service Provider Interface,是一种服务发现机制.它是约定在 Classpath 下的 META-INF/services/ 目录里创建一个以服务接口命名的文件,然后文件里面记录的是此 jar 包提供的具体实现类的全限定名. 这样当我们引用了某个 jar 包的时候就可以去找这个 jar 包

  • Java SPI机制原理及代码实例

    SPI的全名为:Service Provider Interface,大多数开发人员可能不熟悉,因为这个是针对厂商或者插件的.在java.util.ServiceLoader的文档里有比较详细的介绍. 简单的总结下 Java SPI 机制的思想.我们系统里抽象的各个模块,往往有很多不同的实现方案,比如日志模块的方案,xml解析模块.jdbc模块的方案等.面向的对象的设计里,我们一般推荐模块之间基于接口编程,模块之间不对实现类进行硬编码. 一旦代码里涉及具体的实现类,就违反了可拔插的原则,如果需要

  • 一文搞懂Java的SPI机制(推荐)

    目录 1 简介 缺点 源码 使用 适用场景 插件扩展 案例 1 简介 SPI,Service Provider Interface,一种服务发现机制. 有了SPI,即可实现服务接口与服务实现的解耦: 服务提供者(如 springboot starter)提供出 SPI 接口.身为服务提供者,在你无法形成绝对规范强制时,适度"放权" 比较明智,适当让客户端去自定义实现 客户端(普通的 springboot 项目)即可通过本地注册的形式,将实现类注册到服务端,轻松实现可插拔 缺点 不能按需

  • Java中的SPI机制案例分享

    目录 1 简单介绍 2 SPI 案例 3 SPI 的原理剖析 1 简单介绍 当我们封装了一套接口,其它项目想要调用我们的接口只需要引入我们写好的包,但是其它项目如果想要对我们的接口进行扩展,由于接口是被封装在依赖包中的,想要扩展并不容易,这时就需要依赖于Java为我们提供的SPI机制. SPI的全称是Service Provider Interface,服务提供者接口,而与之最接近的概念就是API,全称Application Programming Interface,应用程序编程接口.那么这两

  • Java深入讲解SPI的使用

    目录 什么是Java SPI Java SPI使用demo SPI在JDBC中的应用 SPI在sharding-jdbc中的应用 扩展 什么是Java SPI     SPI的全名为:Service Provider Interface.在java.util.ServiceLoader的文档里有比较详细的介绍.简单的总结下 Java SPI 机制的思想.我们系统里抽象的各个模块,往往有很多不同的实现方案,比如日志模块的方案,xml解析模块.jdbc模块的方案等.面向的对象的设计里,我们一般推荐模

  • Java SPI用法案例详解

    1.什么是SPI      SPI全称Service Provider Interface,是Java提供的一套用来被第三方实现或者扩展的接口,它可以用来启用框架扩展和替换组件. SPI的作用就是为这些被扩展的API寻找服务实现. 2.SPI和API的使用场景     API (Application Programming Interface)在大多数情况下,都是实现方制定接口并完成对接口的实现,调用方仅仅依赖接口调用,且无权选择不同实现. 从使用人员上来说,API 直接被应用开发人员使用.

  • 浅析Java中的SPI原理

    在面向对象的程序设计中,模块之间交互采用接口编程,通常情况下调用方不需要知道被调用方的内部实现细节,因为一旦涉及到了具体实现,如果需要换一种实现就需要修改代码,这违反了程序设计的"开闭原则".所以我们一般有两种选择:一种是使用API(Application Programming Interface),另一种是SPI(Service Provider Interface),API通常被应用程序开发人员使用,而SPI通常被框架扩展人员使用. 在进入下面学习之前,我们先来再加深一下API和

  • 浅析java中String类型中“==”与“equal”的区别

    一.前言 1.1.首先很多人都知道,String中用"=="比较的是地址,用equals比较的是内容,很多人对此用的是记忆法,通过记忆来加强此的引用,但是其真正的原理其实并不难,当我们真正明白其为什么的时候,用起来也会更加灵活,更加有底气(形容得不太好,朋友别见怪): 二相关知识的准备 类型常量池 运行时常量池 字符串常量池 我们今天讨论的主题是当然是字符串常量池: 为什么在这要把另外两个常量池拿出说一下呢,首先小生我在网上或者cnds上看到很多人在争论字符串常量池是存在与方法区还是堆

  • 在java中使用SPI创建可扩展的应用程序操作

    简介 什么是可扩展的应用程序呢?可扩展的意思是不需要修改原始代码,就可以扩展应用程序的功能.我们将应用程序做成插件或者模块. 这样可以在不修改原应用的基础上,对系统功能进行升级或者定制化. 本文将会向大家介绍如何通过java中的SPI机制实现这种可扩展的应用程序. SPI简介 SPI的全称是Java Service Provider Interface.是java提供的一种服务发现的机制. 通过遵循相应的规则编写应用程序之后,就可以使用ServiceLoader来加载相应的服务了. SPI的实现

  • 深入理解Java中的SPI机制

    本文通过探析JDK提供的,在开源项目中比较常用的Java SPI机制,希望给大家在实际开发实践.学习开源项目提供参考. 1 SPI是什么 SPI全称Service Provider Interface,是Java提供的一套用来被第三方实现或者扩展的API,它可以用来启用框架扩展和替换组件. 整体机制图如下: Java SPI 实际上是"基于接口的编程+策略模式+配置文件"组合实现的动态加载机制. 系统设计的各个抽象,往往有很多不同的实现方案,在面向的对象的设计里,一般推荐模块之间基于接

  • 浅析Java中为什么要设计包装类

    目录 一.为什么需要包装类 二.装箱与拆箱 三.不简单的 Integer.valueOf 四.Object 类可以接收所有数据类型 五.包装类在集合中的广泛使用 六.数据类型转换 一.为什么需要包装类 在 Java 中,万物皆对象,所有的操作都要求用对象的形式进行描述.但是 Java 中除了对象(引用类型)还有八大基本类型,它们不是对象.那么,为了把基本类型转换成对象,最简单的做法就是将基本类型作为一个类的属性保存起来,也就是把基本数据类型包装一下,这也就是包装类的由来. 这样,我们先自己实现一

  • JAVA中的SPI思想介绍

    目录 1. SPI介绍 2. SPI规则 3. SPI案例 3.1 组件的定义 3.2 组件的实现 3.3 组件的选用 4. SPI原理 5. SPI要求 6. SPI应用 总结 1. SPI介绍 SPI全称Service Provider Interface,是Java提供的一套用来被第三方实现或者扩展的接口,其意义在于为某个接口寻找服务的实现,主要应用在框架中用来寻找组件,提高扩展性. 汽车制造是一个比较繁琐的过程,通常的手段是先规定汽车各个零部件的生产规格,各个零部件厂商按照这种规则去生产

  • 一文带你了解Java中的SPI机制

    目录 1: SPI机制简介 2: SPI原理 3: 使用场景 4: 源码论证 5: 实战 6: 优缺点 6.1 优点 6.2 缺点 1: SPI机制简介 SPI 全称是 Service Provider Interface,是一种 JDK 内置的动态加载实现扩展点的机制,通过 SPI 技术我们可以动态获取接口的实现类,不用自己来创建.这个不是什么特别的技术,只是 一种设计理念. 2: SPI原理 Java SPI 实际上是基于接口的编程+策略模式+配置文件组合实现的动态加载机制. 系统设计的各个

  • 浅析java中stringBuilder的用法

    String对象是不可改变的.每次使用 System.String类中的方法之一时,都要在内存中创建一个新的字符串对象,这就需要为该新对象分配新的空间.在需要对字符串执行重复修改的情况下,与创建新的 String对象相关的系统开销可能会非常昂贵.如果要修改字符串而不创建新的对象,则可以使用System.Text.StringBuilder类.例如,当在一个循环中将许多字符串连接在一起时,使用 StringBuilder类可以提升性能. 通过用一个重载的构造函数方法初始化变量,可以创建 Strin

  • Java中synchronized实现原理详解

    记得刚刚开始学习Java的时候,一遇到多线程情况就是synchronized,相对于当时的我们来说synchronized是这么的神奇而又强大,那个时候我们赋予它一个名字"同步",也成为了我们解决多线程情况的百试不爽的良药.但是,随着我们学习的进行我们知道synchronized是一个重量级锁,相对于Lock,它会显得那么笨重,以至于我们认为它不是那么的高效而慢慢摒弃它. 诚然,随着Javs SE 1.6对synchronized进行的各种优化后,synchronized并不会显得那么

随机推荐