通过前面介绍Dubbo中的SPI及其自适应的文章中，示例案例中自定义了扩展接口而不是使用Dubbo已提供的扩展接口。在案例中，主程序分别使用了不同的加载方法，如下：

　　

 　　

 　　

　　从ExtensionLoader扩展点加载类注释分析：

　　　　

　　图中红框中的三个类是配合使用，如果在单进程中存在多dubbo服务应用是需要同时重构这三个类的。同时dubbo扩展点加载要点如下：

　　　　1、自动注入依赖的扩展点(springframewok)；

　　　　2、在包装器中自动包装扩展点；

　　　　3、默认扩展需是一个自适应的实例。

　　之前文章中Dubbo中SPI对JDK标准的SPI的一个改进就是：

　　　　

 　　这个改进点如何体现的呢？通过对dubbo提供的已有的扩展点的使用，即主程序执行的过程中并没有显示调用加载的过程就是通过对spring IOC和AOP的支持解决了。

　　本文通过上篇中案例跟踪源码分析Dubbo扩展SPI扩展点的实现过程：　

　　　　

　　一、getExtensionLoader 加载过程

　　　　1、实例化ExtensionLoader

　　　　　　

　　　　跟踪到：

　　　　　　

　　　　可知，EXTENTION_LOADERS最开始为空，不同类型loaders创建后放至其中缓存汇总。进一步调试跟踪可知，在触发事件之前，非懒加载bean的过程中，相关extentionloader已保存至缓存：

　　　　　　

　　　　2、分析ExtentionLoader的构造

　　　　　　

　　　　　　可以看到是常见的工厂模式，主要是对type进行三目运算符操作，首先获得ExtensionFactory对象——其本身也是一个扩展点的加载。再对具体扩展点加载器进行。

 　　　　3、具体关注ExtensionFactory

　　　　　　

　　　　　　从扩展点工厂接口中方法声明可知通过类型及名称获取具体的扩展点，与SPI中具体的名称实现挂钩了。

　　　　4、由于ExtensionFactory本身也是一个扩展点，具体看看dubbo对这个扩展点提供的默认实现

　　　　　　

 　　　　　　可以看到有两个：一个apative，一个spi。与注解@adaptive和@SPI挂钩了。至于读取文件的过程，参考Java基于ClassLoder/ InputStream 配合读取配置文件 - 池塘里洗澡的鸭子 - 博客园 (cnblogs.com)。

　　　　5、分析默认扩展工厂的具体实现adaptive=org.apache.dubbo.common.extension.factory.AdaptiveExtensionFactory

　　　　　　该类UML图如下：

　　　　　　

　　　　　　

　　　　完成以上操作后，下列ExtentionLoader对象下列属性更新：

　　　　　　

　　　　总结以上调试，扩展点的加载首先判断扩展点工厂这个扩展点是否加载(是的扩展点工厂也是个扩展点)，没有先将这个扩展点加载。随后利用该扩展点工厂生产Dubbo框架中用到的扩展点。

　　二、根据name获取扩展点的方法 getExtension

　　　　

 　　Dubbo框架多用这个一次性加载需要用到的扩展点，个人理解通JDK中之SPI。

　　三、Adaptive功能实现原理

　　　　

 　　　　分析该段源码即可知如何获取自适应扩展点。

 

 

 

　　未完，待续……