美文网首页
JDBC【4】-- SPI底层原理解析

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

作者: 秦怀杂货店 | 来源:发表于2020-12-26 22:23 被阅读0次

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

    http://aphysia.cn/archives/jdbcspi

    image

    背景:SPI是什么?
    SPI,即是Service Provider Interface,是一种服务提供(接口实现)发现机制,可以通过ClassPath路径下的META-INF/Service文件查找文件,加载里面定义的类。
    一般可以用来启用框架拓展和替换组件,比如在最常见的数据库连接JDBC中,java.sql.Driver,不同的数据库产商可以对接口做不一样的实现,但是JDK怎么知道别人有哪些实现呢?这就需要SPI,可以查找到接口的实现,对其进行操作。
    用两个字解释:解耦

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

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


    image

    核心代码如下:

        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,实现的服务都加载在里面了。

    image

    那我们就看看遍历的时候怎么取的?
    这就涉及到了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的其他方法呢?

    image
    当然是用了默认实现了,其他两个方法都加了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迭代器,触发寻找操作,如果查找了,那么就加载到集合中,下次就不用再找了。

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

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

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

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

    相关文章

      网友评论

          本文标题:JDBC【4】-- SPI底层原理解析

          本文链接:https://www.haomeiwen.com/subject/fhrnnktx.html