【Java】深入理解Java中的spi机制

深入理解Java中的spi机制

SPI全名为Service Provider Interface是JDK内置的一种服务提供发现机制,是Java提供的一套用来被第三方实现或者扩展的API，它可以用来启用框架扩展和替换组件。

JAVA SPI = 基于接口的编程＋策略模式＋配置文件 的动态加载机制

Java SPI的具体约定如下：

当服务的提供者，提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。

而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。

根据SPI的规范我们的服务实现类必须有一个无参构造方法。

为什么一定要在classes中的META-INF/services下呢？

JDK提供服务实现查找的一个工具类：java.util.ServiceLoader

在这个类里面已经写死

// 默认会去这里寻找相关信息
private static final String PREFIX = "META-INF/services/";

常见的使用场景：

• JDBC加载不同类型的数据库驱动
• 日志门面接口实现类加载，SLF4J加载不同提供商的日志实现类
• Spring中大量使用了SPI,
  • 对servlet3.0规范
  • 对ServletContainerInitializer的实现
  • 自动类型转换Type Conversion SPI(Converter SPI、Formatter SPI)等
• Dubbo里面有很多个组件，每个组件在框架中都是以接口的形成抽象出来！具体的实现又分很多种，在程序执行时根据用户的配置来按需取接口的实现

简单的spi实例

整体包结构如下

└─main
    ├─java
    │  └─com
    │      └─xinchen
    │          └─spi
    │              └─App.java
    │              └─IService.java
    │              └─ServiceImplA.java
    │              └─ServiceImplB.java
    └─resources
        └─META-INF
            └─services
                └─com.xinchen.spi.IService

SPI接口

public interface IService {
    void say(String word);
}

具体实现类

public class ServiceImplA implements IService {
    @Override
    public void say(String word) {
        System.out.println(this.getClass().toString() + " say: " + word);
    }
}

public class ServiceImplB implements IService {
    @Override
    public void say(String word) {
        System.out.println(this.getClass().toString() + " say: " + word);
    }
}

/resource/META-INF/services/com.xinchen.spi.IService

com.xinchen.spi.ServiceImplA
com.xinchen.spi.ServiceImplB

Client类

public class App {
    static ServiceLoader<IService> services = ServiceLoader.load(IService.class);

    public static void main(String[] args) {
        for (IService service:services){
            service.say("Hello World!");
        }
    }
}

//    结果：
//    class com.xinchen.spi.ServiceImplA say: Hello World!
//    class com.xinchen.spi.ServiceImplB say: Hello World!

源码解析

java.util.ServiceLoader中的Fied区域

    // 加载具体实现类信息的前缀
    private static final String PREFIX = "META-INF/services/";

    // 需要加载的接口
    // The class or interface representing the service being loaded
    private final Class<S> service;

    // 用于加载的类加载器
    // The class loader used to locate, load, and instantiate providers
    private final ClassLoader loader;

    // 创建ServiceLoader时采用的访问控制上下文
    // The access control context taken when the ServiceLoader is created
    private final AccessControlContext acc;

    // 用于缓存已经加载的接口实现类，其中key为实现类的完整类名
    // Cached providers, in instantiation order
    private LinkedHashMap<String,S> providers = new LinkedHashMap<>();

    // 用于延迟加载接口的实现类
    // The current lazy-lookup iterator
    private LazyIterator lookupIterator;

从ServiceLoader.load(IService.class)进入源码中

    public static <S> ServiceLoader<S> load(Class<S> service) {
        // 获取当前线程上下文的类加载器
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        return ServiceLoader.load(service, cl);
    }

在ServiceLoader.load(service, cl)中

    public static <S> ServiceLoader<S> load(Class<S> service,ClassLoader loader){
        // 返回ServiceLoader的实例
        return new ServiceLoader<>(service, loader);
    }

    private ServiceLoader(Class<S> svc, ClassLoader cl) {
        service = Objects.requireNonNull(svc, "Service interface cannot be null");
        loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
        acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
        reload();
    }

    public void reload() {
        // 清空已经缓存的加载的接口实现类
        providers.clear();
        // 创建新的延迟加载迭代器
        lookupIterator = new LazyIterator(service, loader);
    }   

    private LazyIterator(Class<S> service, ClassLoader loader) {
        // 指定this类中的 需要加载的接口service和类加载器loader
        this.service = service;
        this.loader = loader;
    }

当我们通过迭代器获取对象实例的时候，首先在成员变量providers中查找是否有缓存的实例对象

如果存在则直接返回，否则则调用lookupIterator延迟加载迭代器进行加载

迭代器判断的代码如下

public Iterator<S> iterator() {
        // 返回迭代器
        return new Iterator<S>() {
            // 查询缓存中是否存在实例对象
            Iterator<Map.Entry<String,S>> knownProviders
                = providers.entrySet().iterator();

            public boolean hasNext() {
                // 如果缓存中已经存在返回true
                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();
            }

        };
    }

LazyIterator的类加载

        // 判断是否拥有下一个实例
        private boolean hasNextService() {
            // 如果拥有直接返回true
            if (nextName != null) {
                return true;
            }

            // 具体实现类的全名 ，Enumeration<URL> config
            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;
                }
                // 转换config中的元素，或者具体实现类的真实包结构
                pending = parse(service, configs.nextElement());
            }
            // 具体实现类的包结构名
            nextName = pending.next();
            return true;
        }

        private S nextService() {
            if (!hasNextService())
                throw new NoSuchElementException();
            String cn = nextName;
            nextName = null;
            Class<?> c = null;
            try {
                // 加载类对象
                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 {
                // 通过c.newInstance()实例化
                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
        }

总结

优点

使用Java SPI机制的优势是实现解耦，使得第三方服务模块的装配控制的逻辑与调用者的业务代码分离，而不是耦合在一起。应用程序可以根据实际业务情况启用框架扩展或替换框架组件。

缺点

• 多个并发多线程使用ServiceLoader类的实例是不安全的

• 虽然ServiceLoader也算是使用的延迟加载，但是基本只能通过遍历全部获取，也就是接口的实现类全部加载并实例化一遍。

参考

The Java™ Tutorials

聊聊Dubbo（五）：核心源码-SPI扩展

深入理解Java SPI机制