Dubbo源码分析之SPI

背景

在Dubbo源码学习过程中，首先就遇到了spi机制，看了一下别人写的介绍，感觉还是基础的，而且它在jdbc中也有应用。但我却感觉很陌生。总之Java基础需要不断加强，下面总结一下spi。

一、别人已经做了不错的总结了，参考文章

二、使用demo

1.项目java/main/resources/META-INF/services目录下新建文本文件，文件名为com.alibaba.dubbo.cache.CacheFactory；
2.刚才文件中的文本内容为
        com.alibaba.dubbo.cache.support.jcache.JCacheFactory
        com.alibaba.dubbo.cache.support.lru.LruCacheFactory
3.测试类
public class SpiTest {
    public static void main(String[] args){
        ServiceLoader<CacheFactory> load = ServiceLoader.load(CacheFactory.class);   //ServiceLoader在java.util包中
        Iterator<CacheFactory> iterator = load.iterator();
        while(iterator.hasNext()){
            CacheFactory next = iterator.next();
            System.out.println(next);
        }
    }
}

4.运行效果如下
com.alibaba.dubbo.cache.support.jcache.JCacheFactory@3f99bd52
com.alibaba.dubbo.cache.support.lru.LruCacheFactory@7adf9f5f

Process finished with exit code 0

三、spi源码分析

这么一个简单的例子初看也不知道是干嘛的。感觉就是编写一个接口和几个实现类，然后再根据规则定义个配置文件，最后程序能够根据接口和配置文件，得到所有实现类的实例对象，底层涉及到反射技术。但是具体怎么用？以及Dubbo中spi扩展机制又是什么？这些需要一点点理解消化。先不扯那么远，先来把这个小例子的源码看看，毕竟千里之行始于当下。

<1>ServiceLoader.load(CacheFactory.class)

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

继续

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

有必要看看ServiceLoad的成员方法了，如下

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

继续

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

继续，来看看这个LazyIterator类

小总结：到这里ServiceLoader.load(CacheFactory.class)源码涉及就这多么，关键就是初始化了LazyIterator类（ServiceLoad的私有内部类）的lookupIterator对象，这个对象看样子好像会比较有用。

<2>load.iterator()

    public Iterator<S> iterator() {
        return new Iterator<S>() {               //返回了一个迭代器A

            Iterator<Map.Entry<String,S>> knownProviders
                = providers.entrySet().iterator();     //注意，这个providers是类初始化new的一个空的Map，什么时候真正赋值呢？这里需要注意一下！

            public boolean hasNext() {
                if (knownProviders.hasNext())
                    return true;
                return lookupIterator.hasNext();   //迭代器A的hasNext()方法真正调用的是前面分析的lookupIterator对象的hasNext方法
            }

            public S next() {
                if (knownProviders.hasNext())
                    return knownProviders.next().getValue();
                return lookupIterator.next();      ////迭代器A的next()方法真正调用的是前面分析的lookupIterator对象的next方法
            }

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

        };
    }

小总结：Serviceload返回的迭代器，实际是对前面分析中关键对象lookupIterator的封装。所以关键点就是这个私有内部类的实现了。下面继续对它分析。

<3>LazyIterator私有内部类源码

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

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

        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());    //Class类中的cast(Object obj),强转
                providers.put(cn, p);                   //这里解答了前面提到的providers真正初始话的问题。
                return p;
            } catch (Throwable x) {
                fail(service,
                     "Provider " + cn + " could not be instantiated",
                     x);
            }
            throw new Error();          // This cannot happen
        }

        public boolean hasNext() {
            if (acc == null) {      //权限这里先不考虑
                return hasNextService();
            } else {
                PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {
                    public Boolean run() { return hasNextService(); }
                };
                return AccessController.doPrivileged(action, acc);
            }
        }

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

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

    }

小总结：底层果然是反射，先分析到这

四、JDBC中应用

String url = "jdbc:mysql:///consult?serverTimezone=UTC";
String user = "root";
String password = "root";

Class.forName("com.mysql.jdbc.Driver");   //新的不需要，但有也能运行
Connection connection = DriverManager.getConnection(url, user, password);

新版JDBC不再需要Class.forName()来显式加载jdbc驱动，底层就是利用spi技术提前加载好了。下面是我源码总结图

小总结：这篇文章仅仅小小总结了一下spi,希望以后继续更新更多spi的实际应用分析。回到dubbo学习主线吧（20200309）