Dubbo 的 SPI 机制（三）（Extension 扩展点补充）

相关博客：

Dubbo 的 Extension 主要是基于 SPI 思想实现的自己的 SPI 的工具。

在上一篇博客（Dubbo的SPI机制（二）（Dubbo优化后的SPI实现））中介绍过了，在 getAdaptiveExtension() 方法中，如果instance为null，则调用 createAdaptiveExtension() 方法：

createAdaptiveExtension() 方法：

之前介绍过了 getAdaptiveExtensionClass() 方法，现在来看看 injectExtension() 方法。从字面意思来看，这是一个注入方法（很熟悉有木有）。

先以 AdaptiveCompiler 为例：

有个 set 方法，本身这是一个自适应扩展点。

@Adaptive注解：

@Adaptive如果是加在类上，表示当前类是一个自定义的自适应扩展点

如果是加在方法级别上，表示需要动态创建一个自适应扩展点，也就是Protocol$Adaptive

可以看出 AdaptiveCompiler 是一个自定义的扩展点，再回过头来看 createAdaptiveExtension() 方法：

AdaptiveCompiler 是在类上使用了 @Adaptive 注解：

 private Class<?> getAdaptiveExtensionClass() {
        getExtensionClasses();
        if (cachedAdaptiveClass != null) {
           //这里会直接返回AdaptiveCompiler，不需要再动态创建了
            return cachedAdaptiveClass;
        }
        return cachedAdaptiveClass = createAdaptiveExtensionClass();
    }

再回过头看 injectExtension() 方法，通过 set 方法动态设置扩展点，类似于 Spring 的 set 注入：

那这个 objectFactory 到底是什么呢：

肯定会有一个地方要对它进行初始化：

 private ExtensionLoader(Class<?> type) {
        this.type = type;
        objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
    }

也就是在构造 ExtensionLoader 的时候进行了初始化，这段代码就很熟悉了，之前看到过：