线程池也是Dubbo自动自适应扩展点之一，也可以自定义线程池。Dubbo中已实现的线程池扩展点有：
其中框架提供的线程池都是通过创建真实的业务线程池进行操作的，目前线程池模型中有两个和Java中线程池相对应：
1）fix：表示创建固定大小的线程池。也是Dubbo默认的使用方式，默认创建的执行线程数为200，并且是没有任何等待队列的。所以在极端的情况下可能会存在问题，比如操作大量执行时，可能存在堵塞的情况。
2)cache：创建非固定大小的线程池，当线程不足时，会自动创建新的线程。但是使用的时候需要注意如果突然有高TPS的请求过来，方法没有及时完成，则会造成大量的线程创建，对系统的CPU和负载都是压力。执行越多反而会影响这个系统的效率。
对于自定义线程池，如何实现呢？以fix模式的线程池为例，其缺点很明显因为线程池中的线程数据量不足导致很多业务直到出现问题才会去查看或通过客户反馈得知，无法自敏感应到。如果在创建该类模式的线程池是，通过某些收到对这个线程池进行监控，这样就可以信息及时的扩缩容机器或者告警，不是就解决这个问题了么？
下面通过给Dubbo框架提供的以fixed为ID的FixedThreadPool示例分析：
1、FixedThreadPool的UML图如下：
2、查看ThreadPool接口：
下面以FixedThreadPool为基础实现自定义的线程池扩展：
线程池实现, 这里主要是基于对 FixedThreadPool 中的实现做扩展出线程监控的部分：
SPI声明，创建文件 META-INF/dubbo/org.apache.dubbo.common.threadpool.ThreadPool
在服务提供方项目引入该依赖
在服务提供方项目中设置使用该线程池生成器
为什么这样写呢？前面查看ThreadPool接口的时候，通过@Adaptive注解已经明确key值为threadpool。
5、主执行程序多次发起请求，查看该线程池是否在服务端生效：
消费端未执行前：
消费端执行后：
没有任何与WatchingThreadPool类直接或间接的调用，那么这个扩展点是如何被调用的呢？后续主题文章介绍。
