纯净、安全、绿色的下载网站

首页|软件分类|下载排行|最新软件|IT学院

当前位置:首页IT学院IT技术

Dubbo源码分析之 SPI(一)

yxfree   2019-12-16 我要评论

一、概述

    dubbo SPI 在dubbo的作用是基础性的,要想分析研究dubbo的实现原理、dubbo源码,都绕不过 dubbo SPI,掌握dubbo SPI 是征服dubbo的必经之路。

    本篇文章会详细介绍dubbo SPI相关的内容,通过源码分析,目标是让读者能通过本篇文章,彻底征服dubbo SPI。

    文章的组织方式是先介绍SPI 的概念,通过Java SPI 让大家了解SPI 是什么,怎么用,有一个初步的概念,dubbo的SPI是扩展了Java SPI的内容,自己实现了一个SPI。

二、SPI概念介绍

    SPI全称 Service Provider Interface,是一种服务发现机制。我们编程实现一个功能时,经常先抽象一个interface,内部再定一些方法。具体的实现交给 implments了此接口的类,实现了功能和实现类的分离。

    我们设想一下,如果一个描述汽车功能的interface  Car,存在多个实现类BMW、Benz、Volvo,某个场景调用Car的行驶方法,程序就需要确认到底是需要BMW、Benz、Volvo中的那个类对象。如果硬编码到程序中,固然可以,但是出现了接口和实现类的耦合,缺点也显而易见。

    有办法做到在调用代码中不涉及BMW、Benz、Volvo字符,也随意的指定实现类么?当然,SPI就是解决这个问题。

    SPI的实现方式是,在指定的路径下增加一个文本文件,文件的名称是interface的全限定名(包名+接口名),文件内容每行是一个此接口的实现类的全限定名,多个实现类就会有多行。接口进行调用时,根据接口全限定名,先读取文本文件,解析出具体的实现类,通过反射进行实例化,再调用之。如果增加新的实现类,不需要修改调用代码,只需要在文本文件中增加一行实现类的全限定名即可,删除实现类同理。

三、Java SPI 介绍

    我们先看看Java的SPI怎么实现的,通过一个demo,进行了解。

    先定一个小车的接口,有一个方法 goBeijing():

1 package cn.hui.spi
2 //Car 接口
3 public interface Car {
4 
5     // 开车去北京
6     void goBeijing();
7 
8 }

    我们建三个实现类:

    

 1 package cn.hui.spi.impl;
 2 public class Bmw implements Car{
 3     @Override
 4     public void goBeijing() {
 5         // TODO Auto-generated method stub
 6         System.out.println("开着宝马去北京......");
 7     }
 8 }
 9 
10 package cn.hui.spi.impl;
11 public class Benz implements Car{
12     @Override
13     public void goBeijing() {
14         // TODO Auto-generated method stub
15         System.out.println("开着奔驰去北京........");
16     }
17 }
18 
19 package cn.hui.spi.impl;
20 public class Volvo implements Car {
21     @Override
22     public void goBeijing() {
23         // TODO Auto-generated method stub
24         System.out.println("开着沃尔沃去北京......");
25     }
26 }

    我们在 "META-INF/services" 文件夹下新建一个文件,名称为“cn.hui.spi.Car",文件内容:

    

1 cn.hui.spi.impl.Bmw
2 cn.hui.spi.impl.Benz
3 cn.hui.spi.impl.Volvo

     方法调用的代码如下:

    

 1 import java.util.Iterator;
 2 import java.util.ServiceLoader;
 3 public class App {
 4     
 5     public static void main(String[] args) {
 6         ServiceLoader<Car> serviceLoader = ServiceLoader.load(Car.class);
 7         Iterator<Car> iterator = serviceLoader.iterator();
 8         while(iterator.hasNext()) {
 9             Car car = iterator.next();
10             car.goBeijing();
11         }
12     }
13 }

    打印结果:

1 开着宝马去北京......
2 开着奔驰去北京........
3 开着沃尔沃去北京......

    这个就是Java SPI简单实现方式。

三、Dubbo SPI介绍

    dubbo 在Java SPI的基础上进行了功能扩展,我们再看上面的Java SPI示例,可以发现很明显的问题,对文本文件的加载后,实例化对象是一次性全部进行实例化,得到一个实现类的对象集合,调用的时候循环执行。不能唯一指定一个实现类进行唯一调用。dubbo通过在文本文件中指定每个实现类的key,唯一标识出每个实现类,调用的时候可以指定唯一的一个实现类。同样实例化也不需要一次性全部实例化了,只需要实例化需要调用的类即可。

     同时dubbo还实现了IOC和AOP的功能,接口的实现类之间可以进行相互的注入,了解Spring的同学,应该很清楚IOC和AOP的逻辑,下面我们现在熟悉下dubbo SPI的相关概念,之后在通过一个简单的样例,了解dubbo SPI 的使用。

四、Dubbo SPI关键点

    dubbo SPI的功能主要是通过ExtensionLoader类实现,dubbo启动时,默认扫描三个目录:META-INF/services/、META-INFhttps://cdn9.52xs.com.cn/dubbo/、META-INF/internal/,在这三个目录下的文本文件都会加载解析,文本文件的内容:key=实现类的全限定名。

    dubbo把接口定义为 扩展点,实现类定义为 扩展点实现,所有的扩展点(接口)需要进行@SPI注解,更多的功能和注解我们逐步介绍。

    dubbo在启动的时候扫描文本文件,对文件内容进行解析,但是不会全部进行实例化,只有在调用到具体的扩展点实现时,才会进行特定扩展点的实例化。

    同时dubbo SPI提供自适应扩展、默认扩展、自动激活扩展等功能,我们后面介绍。

五、Dubbo SPI示例

    我们把上面Car接口的例子,改造成基于dubbo SPI的实现。进行配置的文本文件内容。

    在扩展点实现类前都加上key,改为:

1 bmw=cn.hui.spi.impl.Bmw
2 benz=cn.hui.spi.impl.Benz
3 volvo=cn.hui.spi.impl.Volvo

 Car接口改造为:

1 @SPI
2 public interface Car {
3     // 开车去北京
4     void goBeijing();
5 }

扩展点,暂时不做修改,我们看看调用方法:

 1 public class App {
 2     public static void main(String[] args) {
 3         Car car = ExtensionLoader.getExtensionLoader(Car.class).getExtension("bmw");
 4         car.goBeijing();
 5         car = ExtensionLoader.getExtensionLoader(Car.class).getExtension("benz");
 6         car.goBeijing();
 7         car = ExtensionLoader.getExtensionLoader(Car.class).getExtension("volvo");
 8         car.goBeijing();
 9     }
10 }

此时,控制台会出现:

1 开着宝马去北京......
2 开着奔驰去北京........
3 开着沃尔沃去北京......

这个就是简单dubbo使用,复杂的功能我们放到源码分析的时候进行。

六、Dubbo SPI 源码分析

    dubbo SPI的功能主要几种在ExtensionLoader类中实现,分析源码也就主要分析此类,我们通过ExtensionLoader对外提供的方法作为入口进行源码分析。

    需要注意:一个type接口对应一个ExtensionLoader 实例。

    上面的示例中,我们通过 getExtensionLoader(..)方法,获得ExtensionLoader实例,ExtensionLoader类的构造方法是私有的,只能通过此方法获取实例。

    我们先看看此方法:

 1 @SuppressWarnings("unchecked")
 2 public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {
 3     if (type == null) {
 4         throw new IllegalArgumentException("Extension type == null");
 5     }
 6     // 必须是接口
 7     if (!type.isInterface()) {
 8         throw new IllegalArgumentException("Extension type(" + type + ") is not interface!");
 9     }
10     // 必须被@SPI注解
11     if (!withExtensionAnnotation(type)) {
12         throw new IllegalArgumentException("Extension type(" + type + ") is not extension, because WITHOUT @" + SPI.class.getSimpleName() + " Annotation!");
13     }
14     // extension_loaders 为成员变量,是 type---> ExtensionLoader 实例的缓存
15     ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
16     if (loader == null) {
17         // putIfAbsent put不覆盖
18         EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type));
19         loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
20     }
21     return loader;
22 }

我们看到该方法主要是先对type进行校验,再根据type为key,从缓存EXTENSION_LOADERS中获取ExtensionLoader实例,如果缓存没有,则新建一个ExtensionLoader实例,并放入缓存。
注意,我们说过一个type对应一个ExtensionLoader实例,为什么还需要缓存呢,我们再看看 EXTENSION_LOADERS的定义:

// 扩展点接口和对应ExtensionLoader实例的缓存
private static final ConcurrentMap<Class<?>, ExtensionLoader<?>> EXTENSION_LOADERS = new ConcurrentHashMap<Class<?>, ExtensionLoader<?>>();

没错,EXTENSION_LOADERS 是一个static、final修饰的类静态变量。

我们接着看上面,看一下ExtensionLoader的构造方法:

 1 private ExtensionLoader(Class<?> type) {
 2     this.type = type;
 3     // type 为ExtensionFactory时,objectFactory为空
 4     if (type == ExtensionFactory.class) {
 5         objectFactory = null;
 6     } else {
 7         // type为普通接口时,objectFactory为AdaptiveExtensionFactory,负责dubbo spi 的IOC 功能
 8         objectFactory = ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension();
 9     }
10 //        objectFactory = (type == ExtensionFactory.class ? null
11 //                : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
12 }

构造方法私有,不能直接在外部new出实例。

方法内部,参数type赋值给成员变量type,还会进行ExtensionFactory类判断,ExtensionFactory是实现IOC功能的,我们此处暂时绕过,后面进行介绍。
我们总结一下getExtensionLoader(..)方法,绕开ExtensionFactory,就是new 了一个ExtensionLoader对象实例,为成员变量type赋值为扩展点type,对象实例放入EXTENSION_LOADERS 缓存中。
现在我们有了ExtensionLoader实例对象,我们再看看获取type实例的方法:getExtension(..):

 1 @SuppressWarnings("unchecked")
 2 public T getExtension(String name) {
 3     if (name == null || name.length() == 0)
 4         throw new IllegalArgumentException("Extension name == null");
 5     if ("true".equals(name)) {
 6         // 获取默认的扩展实现类
 7         return getDefaultExtension();
 8     }
 9     // Holder仅用于持有目标对象,没有其他逻辑
10     Holder<Object> holder = cachedInstances.get(name);
11     if (holder == null) {
12         cachedInstances.putIfAbsent(name, new Holder<Object>());
13         holder = cachedInstances.get(name);
14     }
15     Object instance = holder.get();
16     if (instance == null) {
17         synchronized (holder) {
18             instance = holder.get();
19             if (instance == null) {
20                 // 创建扩展实例,并设置到holder中
21                 instance = createExtension(name);
22                 holder.set(instance);
23             }
24         }
25     }
26     return (T) instance;
27 }

    方法的入参name为提供配置的文本文件中的key,还记得我们的文本文件中的内容吧,其中一行:bmw=cn.hui.spi.impl.Bmw,此处的name 就是 bmw。 如果name为true,返回getDefaultExtension(),这个方法我们暂时绕过。

 我们看到13行,根据name从cachedInstances中获取Holder对象,很明显 cachedInstances就是一个存放对象的缓存,缓存中没有new一个新的实例,至于Holder,我们看下这个类:

 1 // 持有目标对象
 2 public class Holder<T> {
 3 
 4     private volatile T value;
 5 
 6     public void set(T value) {
 7         this.value = value;
 8     }
 9 
10     public T get() {
11         return value;
12     }
13 
14 }

只是存放对象,没有任何逻辑。

我们接着看到ExtensionLoader类的代码,在拿到holder实例后,我们要从hodler中获取扩展点的实例:

 1 Object instance = holder.get();
 2 if (instance == null) {
 3     synchronized (holder) {
 4         instance = holder.get();
 5         if (instance == null) {
 6             // 创建扩展实例,并设置到holder中
 7             instance = createExtension(name);
 8             holder.set(instance);
 9         }
10     }
11 }

如果holder中没有扩展点的实例,通过双检锁,通过调用 createExtension方法 返回扩展点实例。并放入holder对象中。

到此,我们发现new扩展点实例进到 createExtension方法中。

我们接着分析此方法:

 1 // 创建扩展对象实例
 2 @SuppressWarnings("unchecked")
 3 private T createExtension(String name) {
 4     // 从配置文件中加载所有的扩展类,形成配置项名称到配置类Clazz的映射关系
 5     Class<?> clazz = getExtensionClasses().get(name);
 6     if (clazz == null) {
 7         throw findException(name);
 8     }
 9     try {
10         T instance = (T) EXTENSION_INSTANCES.get(clazz);
11         if (instance == null) {
12             // 通过反射创建实例
13             EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.newInstance());
14             instance = (T) EXTENSION_INSTANCES.get(clazz);
15         }
16         // 向实例中注入依赖,IOC实现
17         injectExtension(instance);
18         // 包装处理
19         // cachedWrapperClasses 加载@SPI配置时赋值,此处进行实例化
20         Set<Class<?>> wrapperClasses = cachedWrapperClasses;
21         if (wrapperClasses != null && !wrapperClasses.isEmpty()) {
22             // 循环创建wrapper实例
23             for (Class<?> wrapperClass : wrapperClasses) {
24                 // 将当前instance作为参数创建wrapper实例,然后向wrapper实例中注入属性值,
25                 // 并将wrapper实例赋值给instance
26                 instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
27             }
28         }
29         return instance;
30     } catch (Throwable t) {
31         throw new IllegalStateException("Extension instance(name: " + name + ", class: " + type + ")  could not be instantiated: " + t.getMessage(), t);
32     }
33 }

    我们看到方法开始就通过 Class<?> clazz = getExtensionClasses().get(name); 获取Class对象,可以直观的看出通过name获得的这个clazz是在配置的文本文件中name对应的扩展点实现类的Class对象,关于getExtensionClasses方法,我们稍后分析,接着往下看:

1 T instance = (T) EXTENSION_INSTANCES.get(clazz);
2 if (instance == null) {
3     // 通过反射创建实例
4     EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.newInstance());
5     instance = (T) EXTENSION_INSTANCES.get(clazz);
6 }

通过clazz对象,从EXTENSION_INSTANCES获取缓存的实例,如果获取不到,通过反射clazz.newInstance() new一个新的实例对象,并放入EXTENSION_INSTANCES中。

我们可以看到,扩展点的实现类 必须要有一个默认无参的构造函数。

接着往下看:

1  // 向实例中注入依赖,IOC实现
2 injectExtension(instance);

此方法是实现IOC功能,我们暂且绕过。

接下来,我们看到:

 1  // 包装处理
 2  // cachedWrapperClasses 加载@SPI配置时赋值,此处进行实例化
 3  Set<Class<?>> wrapperClasses = cachedWrapperClasses;
 4  if (wrapperClasses != null && !wrapperClasses.isEmpty()) {
 5      // 循环创建wrapper实例
 6      for (Class<?> wrapperClass : wrapperClasses) {
 7          // 将当前instance作为参数创建wrapper实例,然后向wrapper实例中注入属性值,
 8          // 并将wrapper实例赋值给instance
 9          instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
10      }
11  }

此处是处理包装类的,我们也暂且绕过。下面就是直接返回扩展点的instance实例了 

1 return instance;

 现在我们还有一个方法没有分析,就是加载扩展点实现类的Class对象的方法getExtensionClasses()。我们现在来看这个方法:

 1 private Map<String, Class<?>> getExtensionClasses() {
 2     Map<String, Class<?>> classes = cachedClasses.get();
 3     if (classes == null) {
 4         synchronized (cachedClasses) {
 5             classes = cachedClasses.get();
 6             if (classes == null) {
 7                 classes = loadExtensionClasses();
 8                 cachedClasses.set(classes);
 9             }
10         }
11     }
12     return classes;
13 }

我们看到,这个方法返回的是一个Map对象,可以确认的是,这个Map存放的是扩展点的所有实现类的Class,Map的key就是配置的文本文件的name。如果缓存cachedClasses 中存在,即返回,如果没有,通过loadExtensionClasses()加载,并设置到cachedClasses中。

我们接着看loadExtensionClasses方法:

 1 private Map<String, Class<?>> loadExtensionClasses() {
 2     // 获取注解 SPI的接口
 3     // type为传入的扩展接口,必须有@SPI注解
 4     final SPI defaultAnnotation = type.getAnnotation(SPI.class);
 5     // 获取默认扩展实现value,如果存在,赋值给cachedDefaultName
 6     if (defaultAnnotation != null) {
 7         String value = defaultAnnotation.value();
 8         if ((value = value.trim()).length() > 0) {
 9             // @SPI value 只能是一个,不能为逗号分割的多个
10             // @SPI value为默认的扩展实现
11             String[] names = NAME_SEPARATOR.split(value);
12             if (names.length > 1) {
13                 throw new IllegalStateException("more than 1 default extension name on extension " + type.getName() + ": " + Arrays.toString(names));
14             }
15             if (names.length == 1)
16                 cachedDefaultName = names[0];
17         }
18     }
19     // 加载三个目录配置的扩展类
20     Map<String, Class<?>> extensionClasses = new HashMap<String, Class<?>>();
21     // META-INFhttps://cdn9.52xs.com.cn/dubbo/internal
22     loadDirectory(extensionClasses, DUBBO_INTERNAL_DIRECTORY);
23     // META-INFhttps://cdn9.52xs.com.cn/dubbo
24     loadDirectory(extensionClasses, DUBBO_DIRECTORY);
25     // META-INF/services/
26     loadDirectory(extensionClasses, SERVICES_DIRECTORY);
27     return extensionClasses;
28 }

我们看到方法内部的逻辑,首先判断扩展点接口type是否用@SPI注解,在前面的方法中,已经判断,如果没有@SPI注解,抛出异常,此处type必定存在@SPI注解。

根据注解获取到defaultAnnotation 对象,目的是拿到@SPI中的value,且value值不能用逗号分隔,只能有一个,赋值给cachedDefaultName。

接着定一个了Map对象extensionClasses,作为方法的返回值,我们知道,这个方法的返回值最后设置到了缓存cachedClasses中。我们看看这个extensionClasses是怎么赋值的。这个对象主要是”经历“了三个方法(其实是同一个方法loadDirectory,只是入参不同)。这三个方法的入参是extensionClasses 和一个目录参数,就是前面我们介绍的dubbo默认三个目录:

1 META-INF/services/
2 META-INFhttps://cdn9.52xs.com.cn/dubbo/
3 META-INFhttps://cdn9.52xs.com.cn/dubbo/internal/

我们再具体看方法loadDirectory的内容:

 1 private void loadDirectory(Map<String, Class<?>> extensionClasses, String dir) {
 2     // 扩展配置文件完整文件路径+文件名
 3     String fileName = dir + type.getName();
 4     try {
 5         Enumeration<java.net.URL> urls;
 6         // 获取类加载器
 7         ClassLoader classLoader = findClassLoader();
 8         if (classLoader != null) {
 9             urls = classLoader.getResources(fileName);
10         } else {
11             urls = ClassLoader.getSystemResources(fileName);
12         }
13         if (urls != null) {
14             while (urls.hasMoreElements()) {
15                 java.net.URL resourceURL = urls.nextElement();
16                 // 加载
17                 loadResource(extensionClasses, classLoader, resourceURL);
18             }
19         }
20     } catch (Throwable t) {
21         logger.error("Exception when load extension class(interface: " + type + ", description file: " + fileName + ").", t);
22     }
23 }

首先组合目录参数和type名称,作为文件的真实路径名,通过加载器进行加载,之后调用loadResource方法,同时extensionClasses 传入该方法。

 1 private void loadResource(Map<String, Class<?>> extensionClasses, ClassLoader classLoader, java.net.URL resourceURL) {
 2     try {
 3         BufferedReader reader = new BufferedReader(new InputStreamReader(resourceURL.openStream(), "utf-8"));
 4         try {
 5             String line;
 6             while ((line = reader.readLine()) != null) {
 7                 // 字符#是注释开始标志,只取#前面的字符
 8                 final int ci = line.indexOf('#');
 9                 if (ci >= 0)
10                     line = line.substring(0, ci);
11                 line = line.trim();
12                 if (line.length() > 0) {
13                     try {
14                         String name = null;
15                         int i = line.indexOf('=');
16                         if (i > 0) {
17                             // 解析出 name 和 实现类
18                             name = line.substring(0, i).trim();
19                             line = line.substring(i + 1).trim();
20                         }
21                         if (line.length() > 0) {
22                             loadClass(extensionClasses, resourceURL, Class.forName(line, true, classLoader), name);
23                         }
24                     } catch (Throwable t) {
25                         IllegalStateException e = new IllegalStateException("Failed to load extension class(interface: " + type + ", class line: " + line + ") in " + resourceURL + ", cause: " + t.getMessage(), t);
26                         exceptions.put(line, e);
27                     }
28                 }
29             }
30         } finally {
31             reader.close();
32         }
33     } catch (Throwable t) {
34         logger.error("Exception when load extension class(interface: " + type + ", class file: " + resourceURL + ") in " + resourceURL, t);
35     }
36 }

 这个方法就简单多了,解析文件流,拿到配置文本文件中的key、value,同时通过Class.forName(..)加载解析出来的扩展点实现类,传入方法loadClass,注意这个方法传入的参数还有存放key、Class的Map对象extensionClasses,以及配置文本文件中的key,我们再看这个方法:

 1 private void loadClass(Map<String, Class<?>> extensionClasses, java.net.URL resourceURL, Class<?> clazz, String name) throws NoSuchMethodException {
 2     // type是否为clazz的超类,clazz是否实现了type接口
 3     // 此处clazz 是扩展实现类的Class
 4     if (!type.isAssignableFrom(clazz)) {
 5         throw new IllegalStateException("Error when load extension class(interface: " + type + ", class line: " + clazz.getName() + "), class " + clazz.getName() + "is not subtype of interface.");
 6     }
 7     // clazz是否注解了 Adaptive 自适应扩展
 8     // 不允许多个类注解Adaptive
 9     // 注解adaptive的实现类,赋值给cachedAdaptiveClass
10     if (clazz.isAnnotationPresent(Adaptive.class)) {
11         if (cachedAdaptiveClass == null) {
12             cachedAdaptiveClass = clazz;
13             // 不允许多个实现类都注解@Adaptive
14         } else if (!cachedAdaptiveClass.equals(clazz)) {
15             throw new IllegalStateException("More than 1 adaptive class found: " + cachedAdaptiveClass.getClass().getName() + ", " + clazz.getClass().getName());
16         }
17         // 是否为包装类,判断扩展类是否提供了参数是扩展点的构造函数
18     } else if (isWrapperClass(clazz)) {
19         Set<Class<?>> wrappers = cachedWrapperClasses;
20         if (wrappers == null) {
21             cachedWrapperClasses = new ConcurrentHashSet<Class<?>>();
22             wrappers = cachedWrapperClasses;
23         }
24         wrappers.add(clazz);
25         // 普通扩展类
26     } else {
27         // 检测 clazz 是否有默认的构造方法,如果没有,则抛出异常
28         clazz.getConstructor();
29         // 此处name为 SPI配置中的key
30         // @SPI配置中key可以为空,此时key为扩展类的类名(getSimpleName())小写
31         if (name == null || name.length() == 0) {
32             // 兼容旧版本
33             name = findAnnotationName(clazz);
34             if (name.length() == 0) {
35                 throw new IllegalStateException("No such extension name for the class " + clazz.getName() + " in the config " + resourceURL);
36             }
37         }
38         // 逗号分割
39         String[] names = NAME_SEPARATOR.split(name);
40         if (names != null && names.length > 0) {
41             // 获取Activate注解
42             Activate activate = clazz.getAnnotation(Activate.class);
43             if (activate != null) {
44                 cachedActivates.put(names[0], activate);
45             }
46             for (String n : names) {
47                 if (!cachedNames.containsKey(clazz)) {
48                     cachedNames.put(clazz, n);
49                 }
50                 // name不能重复
51                 Class<?> c = extensionClasses.get(n);
52                 if (c == null) {
53                     extensionClasses.put(n, clazz);
54                 } else if (c != clazz) {
55                     throw new IllegalStateException("Duplicate extension " + type.getName() + " name " + n + " on " + c.getName() + " and " + clazz.getName());
56                 }
57             }
58         }
59     }
60 }

 方法参数clazz就是传过来的扩展点实现类的Class对象,首先判断是否实现了扩展点type接口。接着判断是否注解了@Adaptive以及是否为包装类isWrapperClass(clazz),这两个分支逻辑 我们暂且绕过,接下来会进行构造器检查,判断是否存在无参构造器,如果name为空,为了兼容老版本 会进行一次name赋值。

此处会再进行一次name的分隔,前门已经知道,name中不会存在逗号的,但经过上面兼容老版本的重新赋值,会再进行一次判断。@Activate注解的判断,我们也暂且绕过。

循环解析过的name字符串,把加载的扩展点实现Class对象和name存放到入参extensionClasses中。

至此,解析、加载配置文本文件的逻辑已经结束。最后的结果主要是有:把加载到的扩展点Class和key存入到缓存对象extensionClasses中,同时设置cachedDefaultName为扩展点注解@SPI中的value。

我们重新回到方法createExtension中,现在我们已经拿到了特定name对应的扩展点实现类的Class对象,如果对象为空,抛出异常。

接着,我们从缓存对象EXTENSION_INSTANCES中,通过Class对象获取实例,如果实例为空,通过clazz.newInstance()创建,并放入EXTENSION_INSTANCES中。

createExtension方法的后面的逻辑:

 1 // 向实例中注入依赖,IOC实现
 2 injectExtension(instance);
 3 // 包装处理
 4 // cachedWrapperClasses 加载@SPI配置时赋值,此处进行实例化
 5 Set<Class<?>> wrapperClasses = cachedWrapperClasses;
 6 if (wrapperClasses != null && !wrapperClasses.isEmpty()) {
 7     // 循环创建wrapper实例
 8     for (Class<?> wrapperClass : wrapperClasses) {
 9         // 将当前instance作为参数创建wrapper实例,然后向wrapper实例中注入属性值,
10         // 并将wrapper实例赋值给instance
11         instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
12     }
13 }

 是拿到扩展点的实例之后,后期的处理,包括对IOC的实现,包装类的处理等功能逻辑,这些知识点,我们稍后进行分析。

七、总结

    总结一下,本篇文章,我们分析了dubbo SPI的主流程,从入门介绍、示例描述到源码分析,主流程基本介绍完了,中间涉及到的@Adaptive、@Activate注解,以及包装类、扩展点实现类的IOC功能等知识点,我们都暂且绕过了,后面我们会在下一篇文章中逐一介绍。


相关文章

网友评论

Copyright 2020 www.ben10gamesx.com 【Win11软件站】 版权所有 软件发布

声明:所有软件和文章来自软件开发商或者作者 如有异议 请与本站联系 点此查看联系方式