〇、前言
在Dubbo的架构设计中，如何可以通过“类插拔”的方式，对其功能进行灵活的扩展或者削弱，那么，SPI起到了极其关键的作用。本篇文章作为分析Dubbo源码的第一篇文章，我们先暂时放下“服务注册发布流程”、“服务启动流程”、“请求处理流程”……这些功能代码的探索，我们先从最基本的一个问题着手，即：Dubbo的增强SPI是如何实现的，只有搞懂了这个问题，我们后续再看其他功能代码的时候，才会更加游刃有余、畅快无阻~
一、整体时序图
在介绍具体源码详情之前，先将动态获得AdaptiveExtension和Extension的整体时序图给大家展示出来，通过下图，大家会对其处理过程有一个大致的了解，时序图如下所示：
二、源码详解
首先，作为源码解析的入口，我们来看一下Provider端如何通过调用dubbo的API方式来使用dubbo注册自己的服务的，代码如下所示：
在上图的代码中，我们可以看到，当我们获得了ServiceConfig实例对象之后，通过一系列的赋值操作，最终通过调用它的export()方法，就实现了服务接口的注册/暴露操作了；那么，我们第一个需要关心的点就是上图红框部分，即：通过new ServiceConfig()创建ServiceConfig实例。在创建的过程中，首先会执行静态全局变量的初始化操作，即：下图红框的变量创建代码，而这部分就是增强SPI代码部分。
2.1> ExtensionLoader.getExtensionLoader(Protocol.class)
首先，我们来解析一下ExtensionLoader类的getExtensionLoader(Class<T> type)方法，该方法的入参type一定要满足非空的接口类型并且使用@SPI注解。那么最初EXTENSION_INSTANCES是空的ConcurrentHashMap。所以，需要创建ExtensionLoader并缓存到EXTENSION_INSTANCES中。
由于入参的type=Protocol.class，所以我们再来看一下new ExtensionLoader(Protocol.class)构造器方法，在其构造方法的内部，我们还需要针对objectFactory进行赋值操作，即：需要调用ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension()来获取ExtensionFactory的适配器扩展实例。
当我们调用getExtensionLoader(ExtensionFactory.class)时，EXTENSION_INSTANCES中依然为空。所以，会以type=ExtensionFactory.class为入参再次调用ExtensionLoader的构造方法，那么此时入参的type等于ExtensionFactory.class，满足type == ExtensionFactory.class ? null：...，所以objectFactory=null；
2.2> getAdaptiveExtension()从缓存中获取适配器扩展实例
由于在ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension()内部逻辑中，调用了ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension。所以，此处调用的getAdaptiveExtension()是type=ExtensionFactory.class的方法。
在该方法内部，通过Double Check的方式对instance是否为null进行了双验证，如果依然为空，我们就可以通过createAdaptiveExtension()方法来创建适配器的扩展对象了。代码如下红框所示：
2.3> createAdaptiveExtension()用于创建适配器扩展实例
在createAdaptiveExtension()方法中，代码比较简单，就一行代码，但是却做了两件大事：
【事件1】通过getAdaptiveExtensionClass()来获得适配器扩展类，并通过newInstance方法创建实例对象；
【事件2】通过injectExtension(...)方法，对扩展点之间的依赖执行自动注入操作。
这两个事件，请见下图中两个红框所示：
2.3.1> getAdaptiveExtensionClass()
该方法的主要作用是：获得适配器扩展类Class对象。方法内部涉及两部分内容：
【首先】加载并缓存拓展类，如果找到了
cachedAdaptiveClass，则进行返回。【其次】如果没找到，则通过代码来组装源码，并通过Compiler编译生成Class；
上面介绍的处理步骤，请见下图中三个红框所示：
2.3.1.1> getExtensionClasses()加载指定文件名的SPI接口类
如果缓存cachedClasses中已存在，则返回。如果不存在，调用loadExtensionClasses()方法获得加载拓展类，并缓存到cachedClasses中
我们来看一下loadExtensionClasses()方法如何进行类加载的
在方法cacheDefaultExtensionName()中，会通过3步骤，针对给@SPI配置了value值缓存到cachedDefaultName中。
【步骤1】获得type类上的@SPI注解
defaultAnnotation；【步骤2】如果
defaultAnnotation不为空的话，则获得注解配置的value值；【步骤3】将value值缓存到
cachedDefaultName中，供后续使用；
上面介绍的处理步骤，请见下图中三个红框所示：
看完cacheDefaultExtensionName方法后，我们再将视野转移到loadDirectory()方法上，该方法是用于加载fileName文件，并解析其中所配置的内容的，由于在SPI的配置文件中，都是以key和value配置的，所以，最终也会将其读取到内存中：
loadResource()方法用于解析fileName文件中的内容，该方法内主要是去取每行配置，然后通过配置文件中的等号（“=”）来分割出key和value，即：
【key】等号的左侧；
【value】等号的右侧；
分割出来后，再通过loadClass来加载value中所配置的Class名称列表，代码如下所示：
loadClass()用于解析并且缓存cachedAdaptiveClass、cachedWrapperClasses、cachedActivates、cachedNames和extensionClasses，具体逻辑如下所示：
【步骤1】如果入参clazz使用了@Adaptive注解，则将这个clazz缓存到cachedAdaptiveClass中；
【步骤2】如果入参clazz是一个Wrapper类（即：存在入参为clazz的构造方法），则将这个clazz缓存到cachedWrapperClasses中；
【步骤3】通过逗号分割value值，即：获得配置文件中的扩展类Class名称数组names；
【步骤4】将names中的类，使用了@Activate注解的类，都缓存到cachedActivates中；
【步骤5】遍历names数组，将name缓存到cachedNames中；
【步骤6】将name和clazz缓存到extensionClasses中；
此处大家需要注意的是，只需要将被缓存的这些缓存名称有个印象即可，先不用着急缓存后要去做什么事情，到后面的解析部分，面纱也会慢慢的撤下，上面步骤相关代码，如下红框所示：
2.3.1.2> createAdaptiveExtensionClass()
分析完上面的代码之后，我们再来回到2.3.1章节的代码部分，如下所示：
我们已经分析完getExtensionClasses()方法了，下面假设如果SPI没有配置Adaptive类，即：cachedAdaptiveClass等于null，则会执行createAdaptiveExtensionClass()方法来通过程序拼装Adaptive源码，然后默认通过JavassistCompiler将适配器源码编译为Class对象。下面我们就来看一下createAdaptiveExtensionClass()方法的具体处理流程。
在该方法中，首先通过调用generate()方法，来获得java源代码（String code），这个就是我们前文提过的——通过程序拼装Adaptive源码，具体拼装过程如下所述：
public String generate() { if (!hasAdaptiveMethod()) { throw new IllegalStateException("No adaptive method exist on extension " + type.getName() + ", refuse to create the adaptive class!"); } StringBuilder code = new StringBuilder(); code.append(generatePackageInfo()); //【拼装包路径】"package %s;\n" code.append(generateImports()); //【拼装类引用】"import %s;\n" code.append(generateClassDeclaration()); //【拼装类声明】"public class %s$Adaptive implements %s {\n" Method[] methods = type.getMethods(); for (Method method : methods) { code.append(generateMethod(method)); //【拼装方法】"public %s %s(%s) %s {\n%s}\n" } code.append('}'); return code.toString(); // 返回拼装后的java源代码 }
获得了拼装好的java源代码code之后，通过AdaptiveCompiler来对java源代码进行编译，生成Class类型的实例对象，如下所示：
我们可以看到，获得Compiler也是通过getAdaptiveExtension()方法获得的，如下所示：
Compiler compiler = ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();
但是由于Compiler配置了适配器类AdaptiveCompiler（见下图），所以，它不需要通过拼装源码的方式获得适配器类。而是直接返回AdaptiveCompiler类。
2.3.1.3> AdaptiveCompiler.compile()
接下来，我们来看一下，调用了AdaptiveCompiler的compile方法的处理流程，其中主要是执行两个步骤：
【步骤1】首先，通过Dubbo的增强SPI，获得默认扩展
compiler实例对象；【步骤2】然后调用compiler的
compile(...)方法对java源代码code进行编译操作；
代码如下所示：
由于@SPI指定value=“javassist”，所以在执行cacheDefaultExtensionName()方法的时候，cachedDefaultName会被赋值为“javassist”。然后通过name=“javassist”找到缓存过的扩展类loader为JavassistCompiler，那么我们调用的就是JavassistCompiler的getDefaultExtension()方法了，如下所示：
2.3.1.4> getExtension(...)
该getExtension(...)方法中，首先试图去holder中查询是否之前已经创建好了入参name的实例对象。由于我们是第一次运行这个方法，所以自然而然我们从holder中获得的就是null对象了，那么此时我们需要做两个事情：
【步骤1】创建入参
name的扩展类实例对象instance；【步骤2】将instance维护到
holder中，这样如果再想要获得该实例，就可以直接从holder中获取到了。
那么其中比价复杂的就是负责创建instance实例对象的方法createExtension(name)了，如下图红框所示：
通过name=“javassist”从cachedClasses中加载到对应的clazz=org.apache.dubbo.common.compiler.support.JavassistCompiler，因为JavassistCompiler并没有缓存到EXTENSION_INSTANCES中，所以需要调用clazz.newInstance()来创建实例，并缓存到EXTENSION_INSTANCES中去，如下所示：
如上所述，我们就介绍完JavassistCompiler实例的构造过程了。所以，我们再将视野拉回来，看一下compiler.compile(code, classLoader)这段代码，其中，compiler实例对象，其实就是JavassistCompiler实例，如下所示
那么在compile(...)方法中，实际调用的是其父类AbstractCompiler类的compile(...)方法，该方法虽然代码看似很多，但是核心代码其实知识在通过Class.forName来生成Class实例对象这行代码上。如下红框所示：
2.3.2> newInstance()
为什么此处要单单把newInstance()拿出来讲呢？其实醉翁之意不在酒，还记得我们在2.1章节介绍过关于ExtensionFactoy获取AdaptiveExtension的代码吗？为了便于大家回忆，如下红框所示：
那么，当我们针对ExtensionFactoy来调用newInstance()方法时，会执行AdaptiveExtensionFactory的构造方法，该方法内部获得了关于ExtensionFactory类型的的扩展类加载类loader，然后通过调用getSupportedExtensions()方法，获得了“spi”和“spring”。后续我们就可以以spi和spring为key，将org.apache.dubbo.common.extension.ExtensionFactory文件中配置的SpiExtensionFactory和SpringExtensionFactory创建出扩展工厂实例来：
然后，将SpiExtensionFactory和SpringExtensionFactory实例对象保存到factories中，用于后续调用ExtensionFactory.getExtension(...)方法的时候，通过遍历factories，再调用factories.getExtension(type, name)来获得对应的扩展类，代码如下所示：
2.3.3> injectExtension()
通过该方法我们就可以实现扩展类的注入操作了。代码量其实不多，主要逻辑就是通过遍历instance实例的每一个setter方法，过滤掉“不符合”的方法。如果setter方法的入参是一个扩展类，那么就通过objectFactory.getExtension(pt, property)方法获得扩展类对象，并通过反射注入到相应的方法中去，代码&注释如下图所示：
今天的文章内容就这些了：
写作不易，笔者几个小时甚至数天完成的一篇文章，只愿换来您几秒钟的 点赞 & 分享 。
更多技术干货，欢迎大家关注公众号“爪哇缪斯” ~ \(^o^)/ ~ 「干货分享，每天更新」
