Java:深入理解ServiceLoader类与SPI机制

一、SPI接口介绍

SPI(Service Provider Interface),是JDK内置的一种 服务提供发现机制,可以用来启用框架扩展和替换组件,主要是被框架的开发人员使用,比如java.sql.Driver接口,其他不同厂商可以针对同一接口做出不同的实现,MySQL和PostgreSQL都有不同的实现提供给用户,而Java的SPI机制可以为某个接口寻zhao服务实现。Java中SPI机制主要思想是将装配的控制权移到程序之外,在模块化设计中这个机制尤其重要,其核心思想就是 解耦。

JDK自带有ServiceLoader来实现这种机制,当然更为出名的是Spring的SpringFactoriesLoader
(Dubbo也有自己的SPI实现),具体实现方式上都大同小异。
另外,这里所指的Interface并不强要求必须是接口,比如本文里使用均为抽象类,也是一样的可以正常使用。

1.1 SPI与API区别

  • API是类、接口、方法…的描述 ,用于调用并使用它实现一个目标。
  • SPI可用于扩展和实现一个类、接口或者方法…的描述
    换句话说,API 为操作提供特定的类、方法,SPI 通过操作来扩展特定的类、方法。
    参考: https://stackoverflow.com/questions/2954372/difference-between-spi-and-api?answertab=votes#tab-top
    在这里插入图片描述
    当服务的提供者提供了一种接口的实现之后,需要在classpath下的META-INF/services/目录里创建一个以服务接口命名的文件,这个文件里的内容就是这个接口的具体的实现类。当其他的程序需要这个服务的时候,就可以通过查找这个jar包(一般都是以jar包做依赖)的META-INF/services/中的配置文件,配置文件中有接口的具体实现类名,可以根据这个类名进行加载实例化,就可以使用该服务了。JDK中查找服务的实现的工具类是:java.util.ServiceLoader。

1.2 应用场景

SPI扩展机制应用场景有很多,比如Common-Logging,JDBC,Dubbo等等。
SPI流程:

  • 有关组织和公式定义接口标准
  • 第三方提供具体实现: 实现具体方法, 配置 META-INF/services/${interface_name} 文件
  • 开发者使用

比如JDBC场景下:

  • 首先在Java中定义了接口java.sql.Driver,并没有具体的实现,具体的实现都是由不同厂商提供。
  • 在MySQL的jar包mysql-connector-java-6.0.6.jar中,可以找到META-INF/services目录,该目录下会有一个名字为java.sql.Driver的文件,文件内容是com.mysql.cj.jdbc.Driver,这里面的内容就是针对Java中定义的接口的实现。
  • 同样在PostgreSQL的jar包PostgreSQL-42.0.0.jar中,也可以找到同样的配置文件,文件内容是org.postgresql.Driver,这是PostgreSQL对Java的java.sql.Driver的实现。

二、Demo展示

1.定义一个抽象类

package com.googleasy.spi.service;
public abstract class AbstractService {

    public abstract void printMsg();
}

2.完成多个实现

public class TempAServiceImpl extends AbstractService {
    private final static Logger logger = LoggerFactory.getLogger(TempAServiceImpl.class);

    @Override
    public void printMsg() {
        logger.info("this temp A");
    }
}

//--------------------------------------------------------------
public class TempBServiceImpl extends AbstractService {
    private final static Logger logger = LoggerFactory.getLogger(TempBServiceImpl.class);

    @Override
    public void printMsg() {
        logger.info("this temp b");
    }
}

在resources/META-INF/services/目录里创建一个以com.googleasy.spi.service.AbstractService命名的文件,这个文件里的内容就是这个接口的具体的实现类地址,参考如下:
在这里插入图片描述
3.使用 ServiceLoader 来加载配置文件中指定的实现

   @Override
    public void run(String... args) throws Exception {
        ServiceLoader<AbstractService> loaders = ServiceLoader.load(AbstractService.class);
        for (AbstractService loader : loaders) {
            loader.printMsg();
        }
    }

执行输出结果如下:

2020-05-13 13:26:47.421  INFO 16762 --- [           main] c.g.spi.service.impl.TempAServiceImpl    : this temp A
2020-05-13 13:26:47.421  INFO 16762 --- [           main] c.g.spi.service.impl.TempBServiceImpl    : this temp b

三、源码分析

ServiceLoader主要的功能是用来完成对SPI的provider的加载。
先看下它的成员:

public final class ServiceLoader<S>
     implements Iterable<S> {
    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;
    // The access control context taken when the ServiceLoader is created
    private final AccessControlContext acc;
    // Cached providers, in instantiation order
    private LinkedHashMap<String,S> providers = new LinkedHashMap<>();
    // The current lazy-lookup iterator
    private LazyIterator lookupIterator;
    ......
}

可以看到他首先是实现了Iterable接口,可以迭代。

  • PREFIX:指明了路径是在"META-INF/services/"下。
  • service:表示正在加载的服务的类或接口。
  • loader:使用的类加载器。
  • acc:创建ServiceLoader时获取的访问控制上下文。
  • providers:缓存的服务提供集合。
  • lookupIterator:是其内部使用的迭代器,用于类的懒加载,只有在迭代时加载。

其构造方法是一个private方法,不对外提供,在使用时我们需要调用其静态的load方法,由其自身产生ServiceLoader对象:

public static <S> ServiceLoader<S> load(Class<S> service) {
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}
public static <S> ServiceLoader<S> load(Class<S> service,
                                             ClassLoader loader) {
    return new ServiceLoader<>(service, loader);
}

可以看到对load方法进行了重载,其中参数service是要加载的类;单参方法没有类加载器,使用的是当前线程的类加载器;最后调用的是双参的load方法;而双参的load方法也很简单,只是直接调用ServiceLoader的构造方法,实例化了一个对象。

 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();
    }

可以看到其构造方法逻辑依旧很简单,首先是判断传入的svc(即传入的service)是否为空,若是为空直接报异常,否则给service 成员赋值:

    public static <T> T requireNonNull(T obj, String message) {
        if (obj == null)
            throw new NullPointerException(message);
        return obj;
    }

然后给进行cl的非空判断,给loader 成员赋值;接着给acc 成员赋值,其根据是否设置了安全管理器SecurityManager来赋值;最后调用reload方法。

 /**
     * Clear this loader's provider cache so that all providers will be
     * reloaded.
     *
     * <p> After invoking this method, subsequent invocations of the {@link
     * #iterator() iterator} method will lazily look up and instantiate
     * providers from scratch, just as is done by a newly-created loader.
     *
     * <p> This method is intended for use in situations in which new providers
     * can be installed into a running Java virtual machine.
     */
    public void reload() {
        providers.clear();
        lookupIterator = new LazyIterator(service, loader);
    }

可以看到reload方法是一个public方法,那么在每次调用reload时就需要将之前加载的清空掉,所以直接使用providers这个map的clear方法清空掉缓存;接着使用刚才赋值后的service和loader产生一个LazyIterator对象赋值给lookupIterator成员。

LazyIterator是ServiceLoader的内部类,其定义如下:

private class LazyIterator
          implements Iterator<S> {
    Class<S> service;
    ClassLoader loader;
    Enumeration<URL> configs = null;
    Iterator<String> pending = null;
    String nextName = null;
    private LazyIterator(Class<S> service, ClassLoader loader) {
        this.service = service;
        this.loader = loader;
    }
    ......
}

这里就可以看到ServiceLoader的实际加载过程就交给了LazyIterator来做,将ServiceLoader的service和loader成员分别赋值给了LazyIterator的service和loader成员。
configs是服务的URL枚举;
pending是保存要加载的服务的名称集合;
nextName是下一个要加载的服务名称;

ServiceLoader实现了Iterable接口,其实现的iterator方法如下:

 private Iterator<String> parse(Class<?> service, URL u)
        throws ServiceConfigurationError
    {
        InputStream in = null;
        BufferedReader r = null;
        ArrayList<String> names = new ArrayList<>();
        try {
            in = u.openStream();
            r = new BufferedReader(new InputStreamReader(in, "utf-8"));
            int lc = 1;
            while ((lc = parseLine(service, u, r, lc, names)) >= 0);
        } catch (IOException x) {
            fail(service, "Error reading configuration file", x);
        } finally {
            try {
                if (r != null) r.close();
                if (in != null) in.close();
            } catch (IOException y) {
                fail(service, "Error closing configuration file", y);
            }
        }
        return names.iterator();
    }

可以看到它是直接创建了一个Iterator对象返回;其knownProviders成员直接获取providers的entrySet集合的迭代器;在hasNext和next方法中我们可以看到,它是先通过判断knownProviders里有没有(即providers),若没有再去lookupIterator中找;
前面我们可以看到providers里并没用put任何东西,那么就说明put操作也是在lookupIterator中完成的。

先看到lookupIterator的next方法:

public S next() {
    if (acc == null) {
        return nextService();
    } else {
        PrivilegedAction<S> action = new PrivilegedAction<S>() {
            public S run() {
                return nextService();
            }
        }
        ;
        return AccessController.doPrivileged(action, acc);
    }
}

首先根据判断acc是否为空,若为空则说明没有设置安全策略直接调用nextService方法,否则以特权方式调用nextService方法。

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 {
        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
}

首先根据hasNextService方法判断,若为false直接抛出NoSuchElementException异常,否则继续执行。

hasNextService方法:

private Boolean hasNextService() {
    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;
}

hasNextService方法首先根据nextName成员是否为空判断,若不为空,则说明已经初始化过了,直接返回true,否则继续执行。接着configs成员是否为空,configs 是一个URL的枚举,若是configs 没有初始化,就需要对configs初始化。
configs初始化逻辑也很简单,首先根据PREFIX前缀加上PREFIX的全名得到完整路径,再根据loader的有无,获取URL的枚举。其中fail方法时ServiceLoader的静态方法,用于异常的处理,后面给出。
在configs初始化完成后,还需要完成pending的初始化或者添加。
可以看到只有当pending为null,或者没有元素时才进行循环。循环时若是configs里没有元素,则直接返回false;否则调用ServiceLoader的parse方法,通过service和URL给pending赋值;

parse方法:

private Iterator<String> parse(Class<?> service, URL u)
        throws ServiceConfigurationError
    {
        InputStream in = null;
        BufferedReader r = null;
        ArrayList<String> names = new ArrayList<>();
        try {
            in = u.openStream();
            r = new BufferedReader(new InputStreamReader(in, "utf-8"));
            int lc = 1;
            while ((lc = parseLine(service, u, r, lc, names)) >= 0);
        } catch (IOException x) {
            fail(service, "Error reading configuration file", x);
        } finally {
            try {
                if (r != null) r.close();
                if (in != null) in.close();
            } catch (IOException y) {
                fail(service, "Error closing configuration file", y);
            }
        }
        return names.iterator();
    }

可以看到parse方法直接通过URL打开输入流,通过parseLine一行一行地读取将结果保存在names数组里。

parseLine方法:

private int parseLine(Class<?> service, URL u, BufferedReader r, int lc,
                          List<String> names)
        throws IOException, ServiceConfigurationError
    {
        String ln = r.readLine();
        if (ln == null) {
            return -1;
        }
        int ci = ln.indexOf('#');
        if (ci >= 0) ln = ln.substring(0, ci);
        ln = ln.trim();
        int n = ln.length();
        if (n != 0) {
            if ((ln.indexOf(' ') >= 0) || (ln.indexOf('\t') >= 0))
                fail(service, u, lc, "Illegal configuration-file syntax");
            int cp = ln.codePointAt(0);
            if (!Character.isJavaIdentifierStart(cp))
                fail(service, u, lc, "Illegal provider-class name: " + ln);
            for (int i = Character.charCount(cp); i < n; i += Character.charCount(cp)) {
                cp = ln.codePointAt(i);
                if (!Character.isJavaIdentifierPart(cp) && (cp != '.'))
                    fail(service, u, lc, "Illegal provider-class name: " + ln);
            }
            if (!providers.containsKey(ln) && !names.contains(ln))
                names.add(ln);
        }
        return lc + 1;
    }

parseLine方法就是读该URL对应地文件地一行,可以看到通过对“#”的位置判断,忽略注释,并且剔除空格,接着是一系列的参数合法检验,然后判断providers和names里是否都没包含这个服务名称,若都没包含names直接add,最后返回下一行的行标;

当parse将所有内容读取完毕,返回names.iterator()赋值给hasNextService中的pending。循环结束,获取pending中的第一个元素赋值给nextName,返回true,hasNextService方法结束。

在nextService方法往下执行时,先用cn保存nextName的值,再让nextName=null,为下一次的遍历做准备;接着通过类加载,加载名为cn的类,再通过该类实例化对象,并用providers缓存起来,最后返回该实例对象。

其中cast方法是判断对象是否合法:

public T cast(Object obj) {
    if (obj != null && !isInstance(obj))
             throw new ClassCastException(cannotCastMsg(obj));
    return (T) obj;
}

至此ServiceLoader的迭代器的next方法结束。其hasNext方法与其类似,就不详细分析了。

而其remove方法就更直接,直接抛出异常来避免可能出现的危险情况:

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

其中使用到的静态fail方法只是抛出异常:

private static void fail(Class<?> service, String msg, Throwable cause)
          throws ServiceConfigurationError {
    throw new ServiceConfigurationError(service.getName() + ": " + msg,
                                                  cause);
}
private static void fail(Class<?> service, String msg)
          throws ServiceConfigurationError {
    throw new ServiceConfigurationError(service.getName() + ": " + msg);
}
private static void fail(Class<?> service, URL u, int line, String msg)
         throws ServiceConfigurationError {
    fail(service, u + ":" + line + ": " + msg);
}

ServiceLoader除了load的两个方法外还有个loadInstalled方法:

public static <S> ServiceLoader<S> loadInstalled(Class<S> service) {
    ClassLoader cl = ClassLoader.getSystemClassLoader();
    ClassLoader prev = null;
    while (cl != null) {
        prev = cl;
        cl = cl.getParent();
    }
    return ServiceLoader.load(service, prev);
}

该方法与load方法不同在于loadInstalled使用的是扩展类加载器,而load使用的是传入进来的或者是线程的上下文类加载器,其他都一样。

ServiceLoader源码分析到此全部结束。

四、总结

SPI的理念:通过动态加载机制实现面向接口编程,提高了框架和底层实现的分离;

  • ServiceLoader 类提供的 SPI 实现方法只能通过遍历迭代的方法实现获得Provider的实例对象,如果要注册了多个接口的实现类,那么显得效率不高;
  • 虽然通过静态方法返回,但是每一次Service.load方法的调用都会产生一个ServiceLoader实例,不属于单例设计模式;
  • ServiceLoader与ClassLoader是类似的,都可以负责一定的类加载工作,但是前者只是单纯地加载特定的类,即要求实现了Service接口的特定实现类;而后者几乎是可以加载所有Java类;
    对于SPi机制的理解有两个要点:
    1. 理解动态加载的过程,知道配置文件是如何被利用,最终找到相关路径下的类文件,并加载的;
    2. 理解 SPI 的设计模式:接口框架 和底层实现代码分离;
  • 之所以将ServiceLoader类内部的迭代器对象称为LazyInterator,是因为在ServiceLoader对象创建完毕时,迭代器内部并没有相关元素引用,只有真正迭代的时候,才会去解析、加载、最终返回相关类(迭代的元素);

缺点:
1.不能按需加载,需要遍历所有的实现,并实例化,然后在循环中才能找到我们需要的实现。如果不想用某些实现类,或者某些类实例化很耗时,它也被载入并实例化了,这就造成了浪费。
2.获取某个实现类的方式不够灵活,只能通过 Iterator 形式获取,不能根据某个参数来获取对应的实现类。
3.多个并发多线程使用 ServiceLoader 类的实例是不安全的。

方案:
针对以上的不足点,我们在SPI机制选择时,可以考虑使用dubbo实现的SPI机制。
具体参考: http://dubbo.apache.org/zh-cn/blog/introduction-to-dubbo-spi.html

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值