SPI

SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。
Java SPI 实际上是“基于接口的编程+策略模式+配置文件”组合实现的动态加载机制。

Java SPI

案例

接口

public interface Hello {void say();
}

实现类

public class LiHello implements Hello{public void say() {System.out.println("li hello");}
}

public class ZhangHello implements Hello{public void say() {System.out.println("zhang hello");}
}

接口全限定名作为文件名，实现类全限定名为内容
在这里插入图片描述
com.wfg.spi.javaspi.LiHello
com.wfg.spi.javaspi.ZhangHello

public class JavaSpi {public static void main(String[] args) {ServiceLoader<Hello> load = ServiceLoader.load(Hello.class);load.forEach(Hello::say);}
}

在这里插入图片描述

调用过程：
应用程序调用ServiceLoader.load方法，创建一个新的ServiceLoader，并实例化该类中的成员变量

应用程序通过迭代器接口获取对象实例，ServiceLoader先判断成员变量providers对象中(LinkedHashMap类型)是否有缓存实例对象，如果有缓存，直接返回。

如果没有缓存，执行类的装载，

优缺点

优点

使用 Java SPI 机制的优势是实现解耦，使得接口的定义与具体业务实现分离，而不是耦合在一起。应用进程可以根据实际业务情况启用或替换具体组件。

缺点

不能按需加载。虽然 ServiceLoader 做了延迟载入，但是基本只能通过遍历全部获取，也就是接口的实现类得全部载入并实例化一遍。如果你并不想用某些实现类，或者某些类实例化很耗时，它也被载入并实例化了，这就造成了浪费。
获取某个实现类的方式不够灵活，只能通过 Iterator 形式获取，不能根据某个参数来获取对应的实现类。
多个并发多线程使用 ServiceLoader 类的实例是不安全的。
加载不到实现类时抛出并不是真正原因的异常，错误很难定位。

Spring SPI

Dubbo SPI

概述

Dubbo 并未使用 Java SPI，而是重新实现了一套功能更强的 SPI 机制。Dubbo SPI 的相关逻辑被封装在了 ExtensionLoader 类中，通过 ExtensionLoader，我们可以加载指定的实现类。

案例

此时只写和java不同的地方
接口上添加@SPI 注解

@SPI("hello")
public interface Hello {void say();
}

配置内容是键值对方式，因此可以根据key获取实现类

dubbo会从四个目录读取文件META-INF/dubbo/internal/ 、META-INF/dubbo/ 、META-INF/services/、META-INF/dubbo/external/，文件名为接口的全限定名，内容为键值对，键为短名称（可以理解为spring中的对象的名称），值为实现类

h1=com.wfg.spi.dubbospi.LiHello
h2=com.wfg.spi.dubbospi.ZhangHello

public class DubboSpi {public static void main(String[] args) {ExtensionLoader<Hello> extensionLoader =ExtensionLoader.getExtensionLoader(Hello.class);Hello h1 = extensionLoader.getExtension("h1");h1.say();Hello h2 = extensionLoader.getExtension("h2");h2.say();}
}