面试重点： 来说说Dubbo SPI 机制

SPI是一种简称，全名叫 Service Provider Interface，Java本身提供了一套SPI机制，SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类，这样可以在运行时，动态为接口替换实现类，这也是很多框架组件实现扩展功能的一种手段。

而今天要说的Dubbo SPI机制和Java SPI还是有一点区别的，Dubbo 并未使用 Java 原生的 SPI 机制，而是对他进行了改进增强，进而可以很容易地对Dubbo进行功能上的扩展。

学东西得带着问题去学，我们先提几个问题，再接着看

1.什么是SPI（开头已经解释了）

2.Dubbo SPI和Java原生的有什么区别

3.两种实现应该如何写出来

先定义一个接口：

然后创建两个类，都实现这个Car接口

然后在项目META-INF/services文件夹下创建一个名称为接口的全限定名，com.example.demo.spi.Car。

文件内容写上实现类的全限定名，如下：

最后写一个测试代码：

执行完的输出结果：

Dubbo 使用的SPI并不是Java原生的，而是重新实现了一套，其主要逻辑都在ExtensionLoader类中，逻辑也不难，后面会稍带讲一下

看看使用，和Java的差不了太多，基于前面的例子来看下，接口类需要加上@SPI注解：

实现类不需要改动

配置文件需要放在META-INF/dubbo下面，配置写法有些区别，直接看代码：

最后就是测试类了，先看代码：

执行结果：

@SPI 标记为扩展接口

@Adaptive自适应拓展实现类标志

@Activate 自动激活条件的标记

总结一下两者区别：

使用上的区别Dubbo使用 ExtensionLoader而不是 ServiceLoader了，其主要逻辑都封装在这个类中

配置文件存放目录不一样，Java的在 META-INF/services，Dubbo在 META-INF/dubbo， META-INF/dubbo/internal

Java SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，并且又用不上，会造成大量资源被浪费

Dubbo SPI 增加了对扩展点 IOC 和 AOP 的支持，一个扩展点可以直接 setter 注入其它扩展点

Java SPI加载过程失败，扩展点的名称是拿不到的。比如：JDK 标准的 ScriptEngine，getName() 获取脚本类型的名称，如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在，导致 RubyScriptEngine 类加载失败，这个失败原因是不会有任何提示的，当用户执行 ruby 脚本时，会报不支持 ruby，而不是真正失败的原因

前面的3个问题是不是已经能回答出来了？是不是非常简单

Dubbo SPI使用上是通过ExtensionLoader的getExtensionLoader方法获取一个 ExtensionLoader 实例，然后再通过 ExtensionLoader 的 getExtension 方法获取拓展类对象。这其中，getExtensionLoader 方法用于从缓存中获取与拓展类对应的 ExtensionLoader，如果没有缓存，则创建一个新的实例，直接上代码：

上面这一段代码主要做的事情就是先检查缓存，缓存不存在创建扩展对象

接下来我们看看创建的过程：

这段代码看着繁琐，其实也不难，一共只做了4件事情：

1.通过getExtensionClasses获取所有配置扩展类

2.反射创建对象

3.给扩展类注入依赖

4.将扩展类对象包裹在对应的Wrapper对象里面

我们在通过名称获取扩展类之前，首先需要根据配置文件解析出扩展类名称到扩展类的映射关系表，之后再根据扩展项名称从映射关系表中取出相应的拓展类即可。相关过程的代码如下：

这里也是先检查缓存，若缓存没有，则通过一次双重锁检查缓存，判空。此时如果 classes 仍为 null，则通过 loadExtensionClasses 加载拓展类。下面是 loadExtensionClasses 方法的代码

loadExtensionClasses 方法总共做了两件事情，一是对 SPI 注解进行解析，二是调用 loadDirectory 方法加载指定文件夹配置文件。SPI 注解解析过程比较简单，无需多说。下面我们来看一下 loadDirectory 做了哪些事情

loadDirectory 方法先通过 classLoader 获取所有资源链接，然后再通过 loadResource 方法加载资源。我们继续跟下去，看一下 loadResource 方法的实现

loadResource 方法用于读取和解析配置文件，并通过反射加载类，最后调用 loadClass 方法进行其他操作。loadClass 方法用于主要用于操作缓存，该方法的逻辑如下：

综上，loadClass方法操作了不同的缓存，比如cachedAdaptiveClass、cachedWrapperClasses和cachedNames等等

到这里基本上关于缓存类加载的过程就分析完了，其他逻辑不难，认真地读下来加上Debug一下都能看懂的。

从设计思想上来看的话，SPI是对迪米特法则和开闭原则的一种实现。

开闭原则：对修改关闭对扩展开放。这个原则在众多开源框架中都非常常见，Spring的IOC容器也是大量使用。

迪米特法则：也叫最小知识原则，可以解释为，不该直接依赖关系的类之间，不要依赖；有依赖关系的类之间，尽量只依赖必要的接口。

那Dubbo的SPI为什么不直接使用Spring的呢，这一点从众多开源框架中也许都能窥探一点端倪出来，因为本身作为开源框架是要融入其他框架或者一起运行的，不能作为依赖被依赖对象存在。

再者对于Dubbo来说，直接用Spring IOC  AOP的话有一些架构臃肿，完全没必要，所以自己实现一套轻量级反而是最优解