Dubbo的線程模型中可使用4種線程池
想深入了解線程池原理的同學，可以閱讀我的 線程池那些事 專欄。
我們的線程主要執行2種邏輯，壹是普通IO事件，比如建立連接，斷開連接，二是請求IO事件，執行業務邏輯。
在Dubbo的Dispatcher擴展點會使用到這些線程池，Dispatcher這個擴展點用於決定Netty ChannelHandler中的那些事件在Dubbo提供的線程池中執行。
緩沖線程池，默認配置如下
就默認配置來看，和Executors創建的差不多，存在內存溢出風險。
NamedInternalThreadFactory主要用於修改線程名，方便我們排查問題。
AbortPolicyWithReport對拒絕的任務打印日誌，也是方便排查問題。
從keepAliveTime的配置可以看出來，LimitedThreadPool線程池的特性是線程數 只會增加不會減少 。
Dubbo的默認線程池，固定200個線程，就配置來看和LimitedThreadPool基本壹致。
如果壹定要說區別，那就是FixedThreadPool等到創建完200個線程，再往隊列放任務。而LimitedThreadPool是先放隊列放任務，放滿了之後才創建線程。
我們知道，當線程數量達到corePoolSize之後，只有當workqueue滿了之後，才會增加工作線程。
這個線程池就是對這個特性做了優化，首先繼承ThreadPoolExecutor實現EagerThreadPoolExecutor，對 當前線程池提交的任務數submittedTaskCount 進行記錄。
其次是通過自定義TaskQueue作為workQueue，它會在提交任務時判斷是否currentPoolSize<submittedTaskCount<maxPoolSize，然後通過workQueue的offer方法返回false導致增加工作線程。
為什麽返回false會增加工作線程，我們回顧下ThreadPoolExecutor的execute方法
然後看下TaskQueue的offer方法邏輯
最後看下EagerThreadPoolExecutor是如何統計已提交的任務
壹般來講使用Dubbo的默認配置，我們公司的業務量還沒到需要對線程池進行特殊配置的地步。本文主要目的是，通過壹個成熟框架對線程池的配置點，指導我們在實際使用線程池中需要註意的點。