JDBC【4】-- SPI底层原理解析

前面已经讲过SPI的基本实现原理了，demo也基本实现了，再来说说SPI。

http://aphysia.cn/archives/jdbcspi

背景：SPI是什么？

SPI，即是Service Provider Interface，是一种服务提供（接口实现）发现机制，可以通过ClassPath路径下的META-INF/Service文件查找文件，加载里面定义的类。

一般可以用来启用框架拓展和替换组件，比如在最常见的数据库连接JDBC中，java.sql.Driver,不同的数据库产商可以对接口做不一样的实现，但是JDK怎么知道别人有哪些实现呢？这就需要SPI,可以查找到接口的实现，对其进行操作。

用两个字解释：解耦。

再简单点说？

就是Java核心包不知道第三方的包会怎么实现一个接口，定义了一个规则：你要对这个类拓展，那你就把你的实现类配置到一个文件里面，文件名就是你要拓展的接口，这样子，我只要用ServiceLoader加载接口，我就可以获取到实现类的实例。

对于java核心包来说，我不知道你要怎么实现接口，但是只要你按我说的做，配置好，我就能保证你只要引入你自己的包，我就可以运行到你的代码。

核心代码如下：

    ServiceLoader<DBConnectionService>  serviceLoader= ServiceLoader.load(DBConnectionService.class);

所以我们此时假设自己对ServiceLoader已经十分好奇了,这是什么？这是怎么实现的？这么牛逼？

那就看源码？夜深人静刚刚好，白天也看不下去。

这里需要注意的是，这个ServiceLoader是一个泛型类，实现了Iterable，说明了什么？说明它的功能有一部分和集合是差不多的，可以将多个服务的实现类加载在里面！！！可以通过遍历的方式，一一取出来

先看看ServiceLoader的类成员接口，不急着看load()函数：

public final class ServiceLoader<S>
    implements Iterable<S>
{
    // 读取配置文件的路径
    private static final String PREFIX = "META-INF/services/";

    // 加载的服务类或者接口的实现类
    private final Class<S> service;

    // 类加载器
    private final ClassLoader loader;

    // 访问控制器
    private final AccessControlContext acc;

    // 已加载的服务类集合
    private LinkedHashMap<String,S> providers = new LinkedHashMap<>();

    // 内部类，真正加载服务类的迭代器
    private LazyIterator lookupIterator;

    ...
}

现在来看load()函数,其实里面调用的也还是serviceLoader本身的构造器，两个load方法

• 一个只需要传入需要实现的服务接口service
• 另一个则是需要同时传入类加载器loader

    // 当前线程的类加载器作为默认加载器
    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);
    }

我们还是来看serviceLoader的构造器：

    private ServiceLoader(Class<S> svc, ClassLoader cl) {
        // 要加载的接口
        service = Objects.requireNonNull(svc, "Service interface cannot be null");
        // 加载器，如果为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);
    }

查找加载类的迭代器，到底是什么？从名字来看，是一个懒加载器，就是延迟加载，从名字来看，大概能猜到，这个就是使用的时候才加载，真的是这样么？？？接着看下去：

上面 我们说到ServiceLoader其实是一个泛型类，实现了Iterator接口，说明它可以被遍历，遍历的元素是什么呢？就是上面所说的成员变量LinkedHashMap<String,S> providers，实现的服务都加载在里面了。

那我们就看看遍历的时候怎么取的？

这就涉及到了Iterable接口的方法foreach()了，我们就来看看。

总所周知，Iterable接口的方法如下：

    Iterator<T> iterator();
    default void forEach(Consumer<? super T> action) {
        Objects.requireNonNull(action);
        for (T t : this) {
            action.accept(t);
        }
    }
    default Spliterator<T> spliterator() {
        return Spliterators.spliteratorUnknownSize(iterator(), 0);
    }

那我猜遍历的方法应该被ServiceLoader实现的时候，已经重写了,果不其然：

看获取Iterator的方法实现，我们可以发现一个惊天️密：也就是其实我们遍历的时候，优先是使用已知的集合迭代器，这个集合，就是存储我们的服务提供者的集合，也就是已经加载的服务类集合。如果这个集合已经遍历完成的时候，就会调用查找迭代器去查找，不管next()还是hasNext()方法，都是这样的。

同时已经加载的服务，是不可以被移除的，为了防止这一点，在移除的时候会返回异常。

    public Iterator<S> iterator() {
        return new Iterator<S>() {

            //  被查找到的已知的服务提供者的迭代器
            Iterator<Map.Entry<String,S>> knownProviders
                = providers.entrySet().iterator();

            // 如果已知的迭代器，也就是存储服务提供者的集合迭代器，如果这个有下一个元素，那么就会直接返回true，如果没有那么就会调用查找迭代器的hasNext()
            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();
            }

        };
    }

那Iterator的其他方法呢？



当然是用了默认实现了，其他两个方法都加了default关键字，ServiceLoader没有去实现它，可以不实现，用默认实现就可以。

所以我们的重点是什么？当然是这个lookupIterator，它可是一个延迟加载器，为什么这么说，我觉得应该和上面的分析有关，先遍历已经加载的，然后没有了，才会使用这个延迟查找迭代器，从它的名字就可以很清楚的看出来，这其实就是一个查找的迭代器，别人都是迭代遍历已经存在的元素，它倒好，懒到一定程度了，用来查找。

废话少说，直接看看它怎么实现的，这么 牛！

在回头看看前面初始化的时候，构造是这样子的：

        // 初始化查找加载类的迭代器
        lookupIterator = new LazyIterator(service, loader);

可以看到其实是将需要加载的服务接口以及类加载器传递进来了。

代码精简，看下面的代码加注解，应该很清晰了。

    private class LazyIterator
        implements Iterator<S>
    {
        // 需要加载的服务
        Class<S> service;
        // 类加载器
        ClassLoader loader;
        // 实现类的url（多个）
        Enumeration<URL> configs = null;
        // 实现类的全名（多个）
        Iterator<String> pending = null;
        // 迭代器中下一个实现类的全名
        String nextName = null;

        // 构造器其实没有什么操作，单纯保存
        private LazyIterator(Class<S> service, ClassLoader loader) {
            this.service = service;
            this.loader = loader;
        }

        // 获取下一个
        public S next() {
            // 如果控制访问器是空的
            if (acc == null) {
                // 调用获取下一个元素
                return nextService();
            } else {
                // 特权动作，重写的其实也是调用nextService()
                PrivilegedAction<S> action = new PrivilegedAction<S>() {
                    public S run() { return nextService(); }
                };
                // 通过控制访问器的特权访问，跳过检查
                return AccessController.doPrivileged(action, acc);
            }
        }
        // 是否有下一个元素
        public boolean hasNext() {
            if (acc == null) {
                // 如果访问控制器是null，那么久直接调用hasNextService方法
                return hasNextService();
            } else {
                // 生成特权动作
                PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {
                    public Boolean run() { return hasNextService(); }
                };
                // 使用访问控制器执行特权动作
                return AccessController.doPrivileged(action, acc);
            }
        }

        // 不可以移除
        public void remove() {
            throw new UnsupportedOperationException();
        }

        // 是否有下一个元素
        private boolean hasNextService() {
            // 如果下一个元素的全类名名字不为null，那么肯定是有下一个元素
            if (nextName != null) {
                return true;
            }
            // 如果这个实现类的url是空的，怎么办？加载进去
            if (configs == null) {
                try {
                    // 获取全名
                    String fullName = PREFIX + service.getName();
                    // 如果类加载器是null
                    if (loader == null)
                        // 通过全名，拿到全名的url，这个url其实就是根据名字找到的配置文件的路径
                        configs = ClassLoader.getSystemResources(fullName);
                    else
                        // 否则调用loader自身的方法获取
                        configs = loader.getResources(fullName);
                } catch (IOException x) {
                    fail(service, "Error locating configuration files", x);
                }
            }

            // 如果实现类的全限定类名是空的，那就肯定需要从文件里面读出来呀，因为文件名是接口，里面配置的是接口的实现类，pending保存的就是实现类
            while ((pending == null) || !pending.hasNext()) {
                // 如果需要读取的配置没有要读的了
                if (!configs.hasMoreElements()) {
                    // 直接返回false
                    return false;
                }
                // 否则需要解析配置文件里面的内容
                pending = parse(service, configs.nextElement());
            }
            // 下一个service的名字就更新为读取到的接口实现类，如果文件里面什么都没有配置，那就很有可能是空的。
            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");
            }
            // 判断服务c是不是实现来自于service,两者是不是继承关系
            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
        }
    }

通过上面的代码，其实我们可以清楚的看到，这个延迟加载器，会去读取配置类，以及实现的的接口，将实现类全类名放到configs，然后通过反射的形式构建实例对象，实例化之后才放到providers中，然后返回实现类对象。

值得注意的是，如果访问控制器是空的，那么就会调用特权执行：AccessController.doPrivileged(action, acc);,获取到服务实现的时候，也会判断是不是实现来自于我们需要实现的接口，否则会报错，调用的是service.isAssignableFrom(c)。

上面还有一段解析配置的代码没有说明，补上：

    private Iterator<String> parse(Class<?> service, URL u)
        throws ServiceConfigurationError
    {
        // 输入流
        InputStream in = null;
        // buffer读入
        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();
    }

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

到这里，serviceLoader的内容就解读完毕了，思想挺好的，有两个迭代器，一个是提供服务的集合本身的迭代器，迭代完成之后，才会去使用延迟调用lookup迭代器，触发寻找操作，如果查找了，那么就加载到集合中，下次就不用再找了。

查找的时候，直接根据该路径下的文件，文件名就是接口，接口里面每一行都是接口的实现类。

实例化接口实现类的时候，其实是使用了反射，然后判断类型之后，类型转换成为️上转型，放到已经发现的服务集合中，返回。

【作者简介】：

秦怀，公众号【秦怀杂货店】作者，技术之路不在一时，山高水长，纵使缓慢，驰而不息。这个世界希望一切都很快，更快，但是我希望自己能走好每一步，写好每一篇文章，期待和你们一起交流。

此文章仅代表自己（本菜鸟）学习积累记录，或者学习笔记，如有侵权，请联系作者核实删除。人无完人，文章也一样，文笔稚嫩，在下不才，勿喷，如果有错误之处，还望指出，感激不尽~