SPI是什么
SPI是一种简称，全名叫 Service Provider Interface，Java自己提供了一套SPI机制，SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类，这样能够在运行时，动态为接口替换实现类，这也是不少框架组件实现扩展功能的一种手段。java
而今天要说的Dubbo SPI机制和Java SPI仍是有一点区别的，Dubbo 并未使用 Java 原生的 SPI 机制，而是对他进行了改进加强，进而能够很容易地对Dubbo进行功能上的扩展。web
学东西得带着问题去学，咱们先提几个问题，再接着看数组
1.什么是SPI（开头已经解释了）缓存
2.Dubbo SPI和Java原生的有什么区别ruby
3.两种实现应该如何写出来微信
Java SPI是如何实现的
先定义一个接口：架构
public interface Car {
void startUp();
}
而后建立两个类，都实现这个Car接口app
public class Truck implements Car{
@Override
public void startUp() {
System.out.println("The truck started");
}
}
public class Train implements Car{
@Override
public void startUp() {
System.out.println("The train started");
}
}
而后在项目META-INF/services文件夹下建立一个名称为接口的全限定名，com.example.demo.spi.Car。框架
文件内容写上实现类的全限定名，以下：编辑器
com.example.demo.spi.Train
com.example.demo.spi.Truck
最后写一个测试代码：
public class JavaSPITest {
@Test
public void testCar() {
ServiceLoader<Car> serviceLoader = ServiceLoader.load(Car.class);
serviceLoader.forEach(Car::startUp);
}
}
执行完的输出结果：
The train started
The truck started
Dubbo SPI是如何实现的
Dubbo 使用的SPI并非Java原生的，而是从新实现了一套，其主要逻辑都在ExtensionLoader类中，逻辑也不难，后面会稍带讲一下
看看使用，和Java的差不了太多，基于前面的例子来看下，接口类须要加上@SPI注解：
@SPI
public interface Car {
void startUp();
}
实现类不须要改动
配置文件须要放在META-INF/dubbo下面，配置写法有些区别，直接看代码：
train = com.example.demo.spi.Train
truck = com.example.demo.spi.Truck
最后就是测试类了，先看代码：
public class JavaSPITest {
@Test
public void testCar() {
ExtensionLoader<Car> extensionLoader = ExtensionLoader.getExtensionLoader(Car.class);
Car car = extensionLoader.getExtension("train");
car.startUp();
}
}
执行结果：
The train started
Dubbo SPI中经常使用的注解
-
@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源码分析
Dubbo SPI使用上是经过ExtensionLoader的getExtensionLoader方法获取一个 ExtensionLoader 实例，而后再经过 ExtensionLoader 的 getExtension 方法获取拓展类对象。这其中，getExtensionLoader 方法用于从缓存中获取与拓展类对应的 ExtensionLoader，若是没有缓存，则建立一个新的实例，直接上代码：
public T getExtension(String name) {
if (name == null || name.length() == 0) {
throw new IllegalArgumentException("Extension name == null");
}
if ("true".equals(name)) {
// 获取默认的拓展实现类
return getDefaultExtension();
}
// 用于持有目标对象
Holder<Object> holder = cachedInstances.get(name);
if (holder == null) {
cachedInstances.putIfAbsent(name, new Holder<Object>());
holder = cachedInstances.get(name);
}
Object instance = holder.get();
// DCL
if (instance == null) {
synchronized (holder) {
instance = holder.get();
if (instance == null) {
// 建立扩展实例
instance = createExtension(name);
// 设置实例到 holder 中
holder.set(instance);
}
}
}
return (T) instance;
}
上面这一段代码主要作的事情就是先检查缓存，缓存不存在建立扩展对象
接下来咱们看看建立的过程：
private T createExtension(String name) {
// 从配置文件中加载全部的扩展类，可获得“配置项名称”到“配置类”的映射关系表
Class<?> clazz = getExtensionClasses().get(name);
if (clazz == null) {
throw findException(name);
}
try {
T instance = (T) EXTENSION_INSTANCES.get(clazz);
if (instance == null) {
// 反射建立实例
EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.newInstance());
instance = (T) EXTENSION_INSTANCES.get(clazz);
}
// 向实例中注入依赖
injectExtension(instance);
Set<Class<?>> wrapperClasses = cachedWrapperClasses;
if (wrapperClasses != null && !wrapperClasses.isEmpty()) {
// 循环建立 Wrapper 实例
for (Class<?> wrapperClass : wrapperClasses) {
// 将当前 instance 做为参数传给 Wrapper 的构造方法，并经过反射建立 Wrapper 实例。
// 而后向 Wrapper 实例中注入依赖，最后将 Wrapper 实例再次赋值给 instance 变量
instance = injectExtension(
(T) wrapperClass.getConstructor(type).newInstance(instance));
}
}
return instance;
} catch (Throwable t) {
throw new IllegalStateException("Extension instance (name: " + name + ", class: " +
type + ") couldn't be instantiated: " + t.getMessage(), t);
}
}
这段代码看着繁琐，其实也不难，一共只作了4件事情：
1.经过getExtensionClasses获取全部配置扩展类
2.反射建立对象
3.给扩展类注入依赖
4.将扩展类对象包裹在对应的Wrapper对象里面
咱们在经过名称获取扩展类以前，首先须要根据配置文件解析出扩展类名称到扩展类的映射关系表，以后再根据扩展项名称从映射关系表中取出相应的拓展类便可。相关过程的代码以下：
private Map<String, Class<?>> getExtensionClasses() {
// 从缓存中获取已加载的拓展类
Map<String, Class<?>> classes = cachedClasses.get();
// DCL
if (classes == null) {
synchronized (cachedClasses) {
classes = cachedClasses.get();
if (classes == null) {
// 加载扩展类
classes = loadExtensionClasses();
cachedClasses.set(classes);
}
}
}
return classes;
}
这里也是先检查缓存，若缓存没有，则经过一次双重锁检查缓存，判空。此时若是 classes 仍为 null，则经过 loadExtensionClasses 加载拓展类。下面是 loadExtensionClasses 方法的代码
private Map<String, Class<?>> loadExtensionClasses() {
// 获取 SPI 注解，这里的 type 变量是在调用 getExtensionLoader 方法时传入的
final SPI defaultAnnotation = type.getAnnotation(SPI.class);
if (defaultAnnotation != null) {
String value = defaultAnnotation.value();
if ((value = value.trim()).length() > 0) {
// 对 SPI 注解内容进行切分
String[] names = NAME_SEPARATOR.split(value);
// 检测 SPI 注解内容是否合法，不合法则抛出异常
if (names.length > 1) {
throw new IllegalStateException("more than 1 default extension name on extension...");
}
// 设置默认名称，参考 getDefaultExtension 方法
if (names.length == 1) {
cachedDefaultName = names[0];
}
}
}
Map<String, Class<?>> extensionClasses = new HashMap<String, Class<?>>();
// 加载指定文件夹下的配置文件
loadDirectory(extensionClasses, DUBBO_INTERNAL_DIRECTORY);
loadDirectory(extensionClasses, DUBBO_DIRECTORY);
loadDirectory(extensionClasses, SERVICES_DIRECTORY);
return extensionClasses;
}
loadExtensionClasses 方法总共作了两件事情，一是对 SPI 注解进行解析，二是调用 loadDirectory 方法加载指定文件夹配置文件。SPI 注解解析过程比较简单，无需多说。下面咱们来看一下 loadDirectory 作了哪些事情
private void loadDirectory(Map<String, Class<?>> extensionClasses, String dir) {
// fileName = 文件夹路径 + type 全限定名
String fileName = dir + type.getName();
try {
Enumeration<java.net.URL> urls;
ClassLoader classLoader = findClassLoader();
// 根据文件名加载全部的同名文件
if (classLoader != null) {
urls = classLoader.getResources(fileName);
} else {
urls = ClassLoader.getSystemResources(fileName);
}
if (urls != null) {
while (urls.hasMoreElements()) {
java.net.URL resourceURL = urls.nextElement();
// 加载资源
loadResource(extensionClasses, classLoader, resourceURL);
}
}
} catch (Throwable t) {
logger.error("Exception occurred when loading extension class (interface: " +
type + ", description file: " + fileName + ").", t);
}
}
loadDirectory 方法先经过 classLoader 获取全部资源连接，而后再经过 loadResource 方法加载资源。咱们继续跟下去，看一下 loadResource 方法的实现
private void loadResource(Map<String, Class<?>> extensionClasses, ClassLoader classLoader,
java.net.URL resourceURL) {
try {
BufferedReader reader = new BufferedReader(
new InputStreamReader(resourceURL.openStream(), "utf-8"));
try {
String line;
// 按行读取配置内容
while ((line = reader.readLine()) != null) {
// 定位 # 字符
final int ci = line.indexOf('#');
if (ci >= 0) {
// 截取 # 以前的字符串，# 以后的内容为注释，须要忽略
line = line.substring(0, ci);
}
line = line.trim();
if (line.length() > 0) {
try {
String name = null;
int i = line.indexOf('=');
if (i > 0) {
// 以等于号 = 为界，截取键与值
name = line.substring(0, i).trim();
line = line.substring(i + 1).trim();
}
if (line.length() > 0) {
// 加载类，并经过 loadClass 方法对类进行缓存
loadClass(extensionClasses, resourceURL,
Class.forName(line, true, classLoader), name);
}
} catch (Throwable t) {
IllegalStateException e =
new IllegalStateException("Failed to load extension class...");
}
}
}
} finally {
reader.close();
}
} catch (Throwable t) {
logger.error("Exception when load extension class...");
}
}
loadResource 方法用于读取和解析配置文件，并经过反射加载类，最后调用 loadClass 方法进行其余操做。loadClass 方法用于主要用于操做缓存，该方法的逻辑以下：
private void loadClass(Map<String, Class<?>> extensionClasses, java.net.URL resourceURL,
Class<?> clazz, String name) throws NoSuchMethodException {
if (!type.isAssignableFrom(clazz)) {
throw new IllegalStateException("...");
}
// 检测目标类上是否有 Adaptive 注解
if (clazz.isAnnotationPresent(Adaptive.class)) {
if (cachedAdaptiveClass == null) {
// 设置 cachedAdaptiveClass缓存
cachedAdaptiveClass = clazz;
} else if (!cachedAdaptiveClass.equals(clazz)) {
throw new IllegalStateException("...");
}
// 检测 clazz 是不是 Wrapper 类型
} else if (isWrapperClass(clazz)) {
Set<Class<?>> wrappers = cachedWrapperClasses;
if (wrappers == null) {
cachedWrapperClasses = new ConcurrentHashSet<Class<?>>();
wrappers = cachedWrapperClasses;
}
// 存储 clazz 到 cachedWrapperClasses 缓存中
wrappers.add(clazz);
// 程序进入此分支，代表 clazz 是一个普通的拓展类
} else {
// 检测 clazz 是否有默认的构造方法，若是没有，则抛出异常
clazz.getConstructor();
if (name == null || name.length() == 0) {
// 若是 name 为空，则尝试从 Extension 注解中获取 name，或使用小写的类名做为 name
name = findAnnotationName(clazz);
if (name.length() == 0) {
throw new IllegalStateException("...");
}
}
// 切分 name
String[] names = NAME_SEPARATOR.split(name);
if (names != null && names.length > 0) {
Activate activate = clazz.getAnnotation(Activate.class);
if (activate != null) {
// 若是类上有 Activate 注解，则使用 names 数组的第一个元素做为键，
// 存储 name 到 Activate 注解对象的映射关系
cachedActivates.put(names[0], activate);
}
for (String n : names) {
if (!cachedNames.containsKey(clazz)) {
// 存储 Class 到名称的映射关系
cachedNames.put(clazz, n);
}
Class<?> c = extensionClasses.get(n);
if (c == null) {
// 存储名称到 Class 的映射关系
extensionClasses.put(n, clazz);
} else if (c != clazz) {
throw new IllegalStateException("...");
}
}
}
}
}
综上，loadClass方法操做了不一样的缓存，好比cachedAdaptiveClass、cachedWrapperClasses和cachedNames等等
到这里基本上关于缓存类加载的过程就分析完了，其余逻辑不难，认真地读下来加上Debug一下都能看懂的。
总结
从设计思想上来看的话，SPI是对迪米特法则和开闭原则的一种实现。
开闭原则：对修改关闭对扩展开放。这个原则在众多开源框架中都很是常见，Spring的IOC容器也是大量使用。
迪米特法则：也叫最小知识原则，能够解释为，不应直接依赖关系的类之间，不要依赖；有依赖关系的类之间，尽可能只依赖必要的接口。
那Dubbo的SPI为何不直接使用Spring的呢，这一点从众多开源框架中也许都能窥探一点端倪出来，由于自己做为开源框架是要融入其余框架或者一块儿运行的，不能做为依赖被依赖对象存在。
再者对于Dubbo来讲，直接用Spring IOC AOP的话有一些架构臃肿，彻底不必，因此本身实现一套轻量级反而是最优解
往期推荐
本文分享自微信公众号 - 架构技术专栏（jiagoujishu）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。