執行緒模型

如果事件處理的邏輯能迅速完成，並且不會發起新的 IO 請求，比如只是在記憶體中記個標識，則直接在 IO 執行緒上處理更快，因為減少了執行緒池排程。

但如果事件處理邏輯較慢，或者需要發起新的 IO 請求，比如需要查詢資料庫，則必須派發到執行緒池，否則 IO 執行緒阻塞，將導致不能接收其它請求。

如果用 IO 執行緒處理事件，又在事件處理過程中發起新的 IO 請求，比如在連線事件中發起登入請求，會報“可能引發死鎖”異常，但不會真死鎖。

因此，需要通過不同的派發策略和不同的執行緒池配置的組合來應對不同的場景:

<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />
 

Dispatcher

（1）all 所有訊息都派發到執行緒池，包括請求，響應，連線事件，斷開事件，心跳等。 （2）direct 所有訊息都不派發到執行緒池，全部在 IO 執行緒上直接執行。 （3）message 只有請求響應訊息派發到執行緒池，其它連線斷開事件，心跳等訊息，直接在 IO 執行緒上執行。 （4）execution 只請求訊息派發到執行緒池，不含響應，響應和其它連線斷開事件，心跳等訊息，直接在 IO 執行緒上執行。 （5）connection 在 IO 執行緒上，將連線斷開事件放入佇列，有序逐個執行，其它訊息派發到執行緒池。

ThreadPool

（1）fixed 固定大小執行緒池，啟動時建立執行緒，不關閉，一直持有。(預設) （2）cached 快取執行緒池，空閒一分鐘自動刪除，需要時重建。 （3）limited 可伸縮執行緒池，但池中的執行緒數只會增長不會收縮。只增長不收縮的目的是為了避免收縮時突然來了大流量引起的效能問題。 （4）eager 優先建立Worker執行緒池。在任務數量大於corePoolSize但是小於maximumPoolSize時，優先建立Worker來處理任務。當任務數量大於maximumPoolSize時，將任務放入阻塞佇列中。阻塞佇列充滿時丟擲RejectedExecutionException。(相比於cached:cached在任務數量超過maximumPoolSize時直接丟擲異常而不是將任務放入阻塞佇列)