美文网首页
SPI机制原理解析

SPI机制原理解析

作者: JokAr_ | 来源:发表于2020-03-22 17:55 被阅读0次

看了上篇spi使用后,你或许觉得spi太好用了吧,但或许也有疑问:

  • 为什么只能放在META-INF/services/目录下?为什么要用全路径命名?
  • 他的实现原理是什么?

基于这两个问题,我们深入探究下ServiceLoader源码。

构造函数

    private ServiceLoader(Class<S> svc, ClassLoader cl) {
        service = Objects.requireNonNull(svc, "Service interface cannot be null");
        loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
        // Android-changed: Do not use legacy security code.
        // On Android, System.getSecurityManager() is always null.
        // acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
        reload();
    }
  • service 就是普通的class
  • loader ClassLoader类型变量,如果传空就默认ClassLoader.getSystemClassLoader

可以看到构造函数里调用了reload()方法,且Android的 ClassLoader类没有使用AccessController

reload()方法

    public void reload() {
        providers.clear();
        lookupIterator = new LazyIterator(service, loader);
    }

初始化了两个变量providers是用来缓存class的,lookupIterator是我们获取子类继承的核心处理类了,而 ClassLoader本身继承了Iterableiterator()方法里调用lookupIterator来实现重写方法,ServiceLoader的操作都是通过该变量来实现的

iterator()

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

            Iterator<Map.Entry<String,S>> knownProviders
                = providers.entrySet().iterator();

            public boolean hasNext() {
                //首先检查缓存,缓存没有则从lookupIterator读取
                if (knownProviders.hasNext())
                    return true;
                return lookupIterator.hasNext();
            }

            public S next() {
                //首先检查缓存,缓存没有则从lookupIterator读取
                if (knownProviders.hasNext())
                    return knownProviders.next().getValue();
                return lookupIterator.next();
            }

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

        };
    }

LazyIterator

LazyIteratorIterator的继承类,其两个实现方法hasNext()next()分别调用了hasNextService()nextService()所以我们只要看这两个方法就可以了

hasNextService()

        private boolean hasNextService() {
            //下一个继承类的名字,不为空则直接返回true
            if (nextName != null) {
                return true;
            }
            //初始化配置
            if (configs == null) {
                try {
                    //PREFIX = "META-INF/services/";
                    //路径全名称为:  "META-INF/services/" + 类的名称
                    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;
        }

该方法就是解析我们在META-INF/services/目录下配置的接口全路径名的文件,读取里面的继承类文件名,来判断当前节点是否还有继承类

这里就可以看到了我们的第一个问题:

  • 为什么只能放在META-INF/services/目录下?通过PREFIX变量我们可以看到了原因,该变量定义了路径的位置
  • 为什么要用全路径命名?因为service.getName()获取的就是全路径名

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,
                     // Android-changed: Let the ServiceConfigurationError have a cause.
                     "Provider " + cn + " not found", x);
                     // "Provider " + cn + " not found");
            }
            if (!service.isAssignableFrom(c)) {
                // Android-changed: Let the ServiceConfigurationError have a cause.
                ClassCastException cce = new ClassCastException(
                        service.getCanonicalName() + " is not assignable from " + c.getCanonicalName());
                fail(service,
                     "Provider " + cn  + " not a subtype", cce);
                // 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()获取当前节点的继承子类名称,如果没有会抛出异常
  • 然后通过Class.forName实例化该类
  • 然后通过isAssignableFrom校验获得到的类是否是service的子类
  • 最后通过cast强类型转换为service类型,并添加到providers缓存里返回

整个LazyIterator的实现就介绍完了

这里就解释了第二个问题ServiceLoader实现原理?他通过LazyIterator类获取META-INF/services/目录下接口对应的文件,并读取里面的继承类名,然后通过类实例化返回,最终我们就可以获取到了接口对应实现的子类。

相关文章

  • SPI机制原理解析

    看了上篇spi使用后,你或许觉得spi太好用了吧,但或许也有疑问: 为什么只能放在META-INF/service...

  • dubbo原理:SPI机制(二)

    在上一篇:SPI机制(一)中研究了Dubbo SPI的自适应原理;SPI机制(二)中我们来研究下Dubbo SPI...

  • 逐步深入 Dubbo SPI 原理

    什么是 SPI ? SPI(Service Provider Interface) 是一种服务发现机制, 主要原理...

  • Dubbo第三天

    5. SPI 机制原理 因为dubbo 框架是建立的 SPI 机制上,因此在探寻 dubbo 框架源码前,我们需要...

  • Java SPI 机制解析

    本文以JDBC为例深入讲解 java spi 机制,将帮助你理解:什么是SPI,SPI实现原理,SPI的使用和SP...

  • JAVA SPI解析

    JAVA SPI解析 在阅读Dubbo源码时发现Dubbo针对java的spi机制做了扩展。那么spi究竟是什么呢...

  • Dubbo SPI 机制解析

    从上一篇 Java SPI 机制解析 可以知道 Java SPI 的一些劣势。Dubbo 的扩展点加载从 Java...

  • iOS超级签名

    摘抄自:超级签名-原理/机制/技术细节-完全解析蒲公英:超级签名 超级签名-原理/机制/技术细节-完全解析 随着苹...

  • 八、Dubbo框架源码分析:dubbo扩展机制实现

    一、SPI机制: SPI 全称为 Service Provider Interface,是一种服务发现机制。SPI...

  • dubbo的spi机制

    dubbo的spi机制 dubbo的扩展点加载机制源自于java的spi扩展机制。那么,何为java的spi扩展机...

网友评论

      本文标题:SPI机制原理解析

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