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

　　

 　　

 　　

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

　　　　

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

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

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

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

 　　而对于Dubbo提供的扩展点，主程序执行的过程中并没有显示调用加载的过程，无论是自激活的Filter还是自适应的ThreadPool。那么这样的扩展点在程序运行的哪个节点调用的呢？

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

　　　　

 　　这个改进点如何体现的呢？通过对dubbo提供的已有的扩展点的使用，即主程序执行的过程中并没有显示调用加载的过程就是通过对spring IOC和AOP的支持解决了。之前文章中自定义filter/threadpool的使用可以验证：

　　

　　　

 　　以该文章中关于线程池的扩展点为例，调试分析dubbo扩展点的加载原理。首先看注解版的配置(以服务端为例，那么调用的是自适应的扩展点threadpool)：

　　　　查看配置类：

　　　　　　

 　　　　红框中是典型的Java Bean 的一个应用，就是将扫描目录下的bean和一个RegistryConfig实例化注入到容器中。关于此部分的内容，参考Spring Bean加载全过程相关的内容(Spring Bean加载全过程(注解配置) - 池塘里洗澡的鸭子 - 博客园 (cnblogs.com))。

　　上述配置与扩展点唯一的关联在于配置文件dubbo-provider.properties中，关于线程池配属性的配置：

　　　　

 　　参考Spring Bean的加载，可知该配置保存到数据结构ProviderConfig中：

　　　　

　　那么本文就以watching这个扩展点为切入点阐述扩展点的识别、加载、应用的全过程。

　

  　　根据上面跟踪调试信息，可知watching扩展点的调用在Spring容器初始化完成刷新的过程中调用事件。关于Spring事件的应用，在之前的文章中有涉及可以参考（从命令模式的维度理解Spring 之Application Event - 池塘里洗澡的鸭子 - 博客园 (cnblogs.com)），本文略述：　　

　　　　

　　从跟踪截图上看，listener为DubboBootstrapApplicationListener，ApplicationContextAwareProcessor后置处理DubboApplicationListenerRegistrar时setApplicationContext中添加到容器中专门保存listener的列表中

　　　　

　　后续关于Event的使用就不赘述了。那么扩展点的加载了，到目前为止还没有涉及；以上都是为Event的publish/listener做准备，下面就是本文的重点扩展点了：

　　　　1、事件发布后，事件派发器派发事件给listener　　　　

 　　　　　　

 　　　　　　

 　　　　2、listener响应事件

　　　　　　

 　　　　　　

 　　　　3、dubboBootstrap.start命令中获取扩展点，URL中就包含了扩展点的名字。

　　　　　　

　　通过以上阐述，dubbo中扩展点的加载时机就非常明确了。