轉(zhuǎn)自? https://ifeve.com/dubbo-threadmodel/

Dubbo剖析-線程模型

一、前言

Dubbo默認(rèn)的底層網(wǎng)絡(luò)通訊是使用Netty來做的，在服務(wù)提供方NettyServer使用兩級(jí)線程池，其中

EventLoopGroup(boss)主要用來接受客戶端的鏈接請(qǐng)求，并把接受的請(qǐng)求分發(fā)給EventLoopGroup（worker）來處

理，boss和worker線程組我們稱為IO線程。

如果服務(wù)提供方的邏輯能迅速完成，并且不會(huì)發(fā)起新的 IO 請(qǐng)求，則直接在 IO 線程上處理更快，因?yàn)檫@減少了線程池調(diào)度。

但如果處理邏輯較慢，或者需要發(fā)起新的 IO 請(qǐng)求，比如需要查詢數(shù)據(jù)庫(kù)，則必須派發(fā)到新線程池，否則 IO 線程阻塞，將導(dǎo)致不能接收其它請(qǐng)求。

二、Dubbo提供的線程模型

all 所有消息都派發(fā)到線程池，包括請(qǐng)求，響應(yīng)，連接事件，斷開事件，心跳等,模型如下圖

direct 所有消息都不派發(fā)到線程池，全部在 IO 線程上直接執(zhí)行，模型如下圖

execution 只請(qǐng)求消息派發(fā)到線程池，不含響應(yīng)，響應(yīng)和其它連接斷開事件，心跳等消息，直接在 IO 線程上執(zhí)行，模型如下圖

connection 在 IO 線程上，將連接斷開事件放入隊(duì)列，有序逐個(gè)執(zhí)行，其它消息派發(fā)到線程池。

其中ThreadPool的spi實(shí)現(xiàn)有如下：

fixed 固定大小線程池，啟動(dòng)時(shí)建立線程，不關(guān)閉，一直持有。(缺省)

cached 緩存線程池，空閑一分鐘自動(dòng)刪除，需要時(shí)重建。

limited 可伸縮線程池，但池中的線程數(shù)只會(huì)增長(zhǎng)不會(huì)收縮。只增長(zhǎng)不收縮的目的是為了避免收縮時(shí)突然來了大流量引起的性能問題。

三、總結(jié)

dubbo提供了常用的線程模型和線程池?cái)U(kuò)展各有利弊，如果您有定制化需要，可以按照spi規(guī)范進(jìn)行定制。