Dispatcher
dubbo的Dispatcher策略：
- all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
- direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。
- message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
- execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
- connection 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。
Dispatcher的操作基本都是基于内部维护的一个线程池。线程池的构造是基于ThreadPool对象实现。以这个场景为例，在熟悉这个场景的同时，了解一下dubbo的SPI机制。
在provider中添加一个配置
1.png
在Dispatcher类中，dubbo根据配置来选择具体的dispatcher实现类，我们配置的是all，进入AllDispatcher
2.png
3.png
4.png
AllDispatcherl类直接调用了AllChannelHandler 。AllChannelHandler 又直接调用了父类WrappedChannelHandler的构造方法。所以我们在WrappedChannelHandler类中打下断点
5.png
AllChannelHandler 中对于connected, disconnected, received等事件都是通过线程池cexecutor来完成的，这个cexecutor的构造在它的父类--WrappedChannelHandler 的构造方法中完成。url对象作为参数被传入了线程池的构造方法。
启动系统，断点走到了线程池的构造 方法中。作为参数的url对象长这样
6.png
ExtensionLoader.getExtensionLoader()即通过spi动态的获取配置对应的ThreadPool类，这里我们配置的是cached，查看dubbo的spi配置文件
7.png
如果SPI生效，那么cached对应的应该是CachedThreadPool 这个类。在CachedThreadPool里也打一个断点，验证一下猜测对不对
8.png
果然，在释放掉WrappedChannelHandler构造方法里的断点之后，断点走到了CachedThreadPool 里。说明spi成功的根据配置走到了对应的类。方法也很简单，就是新建了一个ThreadPoolExecutor，ThreadPoolExecutor是jdk自带的线程池实现类。
SPI
ExtensionLoader.getExtensionLoader() ，记住这个方法，是dubbo框架里SPI的一个典型运用，通过给定的扩展加载器来加载需要的类。这里传入了ThreadPool的class对象，即通过配置来加载。
spi技术类似于插件，通过配置文件来对接口的实现进行配置和扩展，将程序装配的控制权移到系统代码之外。java spi的具体约定为:当服务的提供者，提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。
还是以ThreadPool的加载为例来看看dubbo的SPI是怎么把类给加载进来的。从ExtensionLoader.getAdaptiveExtension一路追踪。
9.png
可以看到实例是在createAdaptiveExtension方法中被加载出来。进入这个方法
10.png
先用getAdaptiveExtensionClass().newInstance()获取目标实例，然后传入injectExtension
injectExtension这个方法稍后再分析，先进入getAdaptiveExtensionClass方法中
getAdaptiveExtensionClass
在这个方法中先调用getExtensionClasses方法将配置文件里的类缓存，然后调用createAdaptiveExtensionClass。
11.png
getExtensionClasses
进入到getExtensionClasses方法中
12.png
方法中又调用了loadExtensionClasses方法。进入loadExtensionClasses方法。loadExtensionClasses主要是获取类上的SPI注解，并拿到注解的值。随后调用loadFile对配置目录进行扫描
13.png
重点关注loadFile方法
loadFile根据已经配置完成的目录加上当前的类名，加载出文件的内容，最后解析得到一个url对象。url对象中包含了我们所需要读取的配置文件的路径等信息
14.png
接下来就是BufferReader，文件按行读取
15.png
解析内容后用Class.forName，创建类的实例
16.png
将配置文件里的类全部读出来然后统一实例化，并且缓存到extensionClasses里
回到getAdaptiveExtensionClass方法中，代码进入到createAdaptiveExtensionClass
17.png
createAdaptiveExtensionClass
此时程序执行进入到createAdaptiveExtensionClass方法。
19.png
首先进入到createAdaptiveExtensionClassCode方法获取目标类的代理类的代码。
type，也就是我们要加载的类是ThreadPool类。首先反射获取了类所有的方法，并且逐一判断方法有没有Adaptive注解，很显然，ThreadPool有一个方法getExecutor，且方法上存在Adaptive注解。完全符合条件，代码继续执行。
18.png
20.png
接下来就开始咔咔拼代码，我们可以看到拼完之后的，整个字符串基本上就是一个类的开头。为目标类的代理类开始写代码。
21.png
22.png
类的头写完了，接下来开始写类里的代码。循环method数组，判断这个方法是否有Adaptive注解，从断点我们可以得知，这个方法上注解的值是threadpool
23.png
注解不为空代码继续下行，进行参数的校验。如果参数中存在URL类型的参数，那么需要做一个特殊处理，即参数不能为null，添加一个参数的校验，为null抛出异常。
24.png
很不巧的是我们的ThreadPool的getExecute方法的参数正好是URL对象。于是代码中就会被加上了这么一句。
25.png
接下来是一些判断，例如注解的值是不是空的，参数类型是不是Invocation等等，不巧的是ThreadPool都不符合，所以全部跳过。接下来就是正式开始用我们的参数加载返回值了
26.png
从上面这串代码可以看到，对于ThreadPool，dubbo有一个默认的配置，是fixed，也就是说如果你不配，那就是初始化fixed。另外对于Invocation类型，代码的写法也有所不同，难怪要先进行判断。
接下来又是一系列的代码拼装，空值校验之类的
27.png
拼装完之后，代码已经被写成了下边这样
28.png
至此 ，createAdaptiveExtensionClassCode执行完毕，成功获取到代理类的所有代码。随后将这堆字符串原地编译，编译出代理类并返回。
29.png
终于，代码又回到了createAdaptiveExtension中。随后执行injectExtension方法
30.png
这个方法中的操作也不复杂，判断是否有属性需要注入，如果有的话就注入
31.png
遗憾的是，我们的ThreadPool类并没有这样的方法。
所以最终返回的实例就是前一步编译完成的代理对象。ExtensionLoader.getAdaptiveExtension方法到此结束。
ExtensionLoader是dubbo对SPI机制的一个封装。基本上所有的扩展点特性都在这个类里实现。了解了这个类也基本上就明白了SPI机制的实现
网友评论