IO多路復(fù)用,幾個(gè)動(dòng)圖我悟了!

為了講多路復(fù)用，當(dāng)然還是要跟風(fēng)，采用鞭尸的思路，先講講傳統(tǒng)的網(wǎng)絡(luò) IO 的弊端，用拉踩的方式捧起多路復(fù)用 IO 的優(yōu)勢(shì)。

為了方便理解，以下所有代碼都是偽代碼，知道其表達(dá)的意思即可。

Let's go

阻塞 IO

服務(wù)端為了處理客戶端的連接和請(qǐng)求的數(shù)據(jù)，寫了如下代碼。

listenfd?=?socket();???//?打開一個(gè)網(wǎng)絡(luò)通信端口
bind(listenfd);????????//?綁定
listen(listenfd);??????//?監(jiān)聽
while(1)?{
??connfd?=?accept(listenfd);??//?阻塞建立連接
??int?n?=?read(connfd,?buf);??//?阻塞讀數(shù)據(jù)
??doSomeThing(buf);??//?利用讀到的數(shù)據(jù)做些什么
??close(connfd);?????//?關(guān)閉連接，循環(huán)等待下一個(gè)連接
}

這段代碼會(huì)執(zhí)行得磕磕絆絆，就像這樣。

可以看到，服務(wù)端的線程阻塞在了兩個(gè)地方，一個(gè)是 accept 函數(shù)，一個(gè)是 read 函數(shù)。

如果再把 read 函數(shù)的細(xì)節(jié)展開，我們會(huì)發(fā)現(xiàn)其阻塞在了兩個(gè)階段。

這就是傳統(tǒng)的阻塞 IO。

整體流程如下圖。

所以，如果這個(gè)連接的客戶端一直不發(fā)數(shù)據(jù)，那么服務(wù)端線程將會(huì)一直阻塞在 read 函數(shù)上不返回，也無法接受其他客戶端連接。

這肯定是不行的。

非阻塞 IO

?

為了解決上面的問題，其關(guān)鍵在于改造這個(gè) read 函數(shù)。

有一種聰明的辦法是，每次都創(chuàng)建一個(gè)新的進(jìn)程或線程，去調(diào)用 read 函數(shù)，并做業(yè)務(wù)處理。

while(1)?{
??connfd?=?accept(listenfd);??//?阻塞建立連接
??pthread_create（doWork);??//?創(chuàng)建一個(gè)新的線程
}
void?doWork()?{
??int?n?=?read(connfd,?buf);??//?阻塞讀數(shù)據(jù)
??doSomeThing(buf);??//?利用讀到的數(shù)據(jù)做些什么
??close(connfd);?????//?關(guān)閉連接，循環(huán)等待下一個(gè)連接
}

這樣，當(dāng)給一個(gè)客戶端建立好連接后，就可以立刻等待新的客戶端連接，而不用阻塞在原客戶端的 read 請(qǐng)求上。

不過，這不叫非阻塞 IO，只不過用了多線程的手段使得主線程沒有卡在 read 函數(shù)上不往下走罷了。操作系統(tǒng)為我們提供的 read 函數(shù)仍然是阻塞的。

所以真正的非阻塞 IO，不能是通過我們用戶層的小把戲，而是要懇請(qǐng)操作系統(tǒng)為我們提供一個(gè)非阻塞的 read 函數(shù)。

這個(gè) read 函數(shù)的效果是，如果沒有數(shù)據(jù)到達(dá)時(shí)（到達(dá)網(wǎng)卡并拷貝到了內(nèi)核緩沖區(qū)），立刻返回一個(gè)錯(cuò)誤值（-1），而不是阻塞地等待。

操作系統(tǒng)提供了這樣的功能，只需要在調(diào)用 read 前，將文件描述符設(shè)置為非阻塞即可。

fcntl(connfd,?F_SETFL,?O_NONBLOCK);
int?n?=?read(connfd,?buffer)?!=?SUCCESS);

這樣，就需要用戶線程循環(huán)調(diào)用 read，直到返回值不為 -1，再開始處理業(yè)務(wù)。

這里我們注意到一個(gè)細(xì)節(jié)。

非阻塞的 read，指的是在數(shù)據(jù)到達(dá)前，即數(shù)據(jù)還未到達(dá)網(wǎng)卡，或者到達(dá)網(wǎng)卡但還沒有拷貝到內(nèi)核緩沖區(qū)之前，這個(gè)階段是非阻塞的。

當(dāng)數(shù)據(jù)已到達(dá)內(nèi)核緩沖區(qū)，此時(shí)調(diào)用 read 函數(shù)仍然是阻塞的，需要等待數(shù)據(jù)從內(nèi)核緩沖區(qū)拷貝到用戶緩沖區(qū)，才能返回。

整體流程如下圖

?

IO 多路復(fù)用

?

為每個(gè)客戶端創(chuàng)建一個(gè)線程，服務(wù)器端的線程資源很容易被耗光。

當(dāng)然還有個(gè)聰明的辦法，我們可以每 accept 一個(gè)客戶端連接后，將這個(gè)文件描述符（connfd）放到一個(gè)數(shù)組里。

fdlist.add(connfd);

然后弄一個(gè)新的線程去不斷遍歷這個(gè)數(shù)組，調(diào)用每一個(gè)元素的非阻塞 read 方法。

while(1)?{
??for(fd?<--?fdlist)?{
????if(read(fd)?!=?-1)?{
??????doSomeThing();
????}
??}
}

這樣，我們就成功用一個(gè)線程處理了多個(gè)客戶端連接。

你是不是覺得這有些多路復(fù)用的意思？

但這和我們用多線程去將阻塞 IO 改造成看起來是非阻塞 IO 一樣，這種遍歷方式也只是我們用戶自己想出的小把戲，每次遍歷遇到 read 返回 -1 時(shí)仍然是一次浪費(fèi)資源的系統(tǒng)調(diào)用。

在 while 循環(huán)里做系統(tǒng)調(diào)用，就好比你做分布式項(xiàng)目時(shí)在 while 里做 rpc 請(qǐng)求一樣，是不劃算的。

所以，還是得懇請(qǐng)操作系統(tǒng)老大，提供給我們一個(gè)有這樣效果的函數(shù)，我們將一批文件描述符通過一次系統(tǒng)調(diào)用傳給內(nèi)核，由內(nèi)核層去遍歷，才能真正解決這個(gè)問題。

?

select

?

select 是操作系統(tǒng)提供的系統(tǒng)調(diào)用函數(shù)，通過它，我們可以把一個(gè)文件描述符的數(shù)組發(fā)給操作系統(tǒng)， 讓操作系統(tǒng)去遍歷，確定哪個(gè)文件描述符可以讀寫， 然后告訴我們?nèi)ヌ幚恚?/span>

select系統(tǒng)調(diào)用的函數(shù)定義如下。

int?select(
????int?nfds,
????fd_set?*readfds,
????fd_set?*writefds,
????fd_set?*exceptfds,
????struct?timeval?*timeout);
//?nfds:監(jiān)控的文件描述符集里最大文件描述符加1
// readfds：監(jiān)控有讀數(shù)據(jù)到達(dá)文件描述符集合，傳入傳出參數(shù)
// writefds：監(jiān)控寫數(shù)據(jù)到達(dá)文件描述符集合，傳入傳出參數(shù)
// exceptfds：監(jiān)控異常發(fā)生達(dá)文件描述符集合, 傳入傳出參數(shù)
// timeout：定時(shí)阻塞監(jiān)控時(shí)間，3種情況
//??1.NULL，永遠(yuǎn)等下去
//??2.設(shè)置timeval，等待固定時(shí)間
//??3.設(shè)置timeval里時(shí)間均為0，檢查描述字后立即返回，輪詢

服務(wù)端代碼，這樣來寫。

首先一個(gè)線程不斷接受客戶端連接，并把 socket 文件描述符放到一個(gè) list 里。

while(1)?{
??connfd?=?accept(listenfd);
??fcntl(connfd,?F_SETFL,?O_NONBLOCK);
??fdlist.add(connfd);
}

然后，另一個(gè)線程不再自己遍歷，而是調(diào)用 select，將這批文件描述符 list 交給操作系統(tǒng)去遍歷。

while(1)?{
??//?把一堆文件描述符?list?傳給?select?函數(shù)
??//?有已就緒的文件描述符就返回，nready?表示有多少個(gè)就緒的
??nready?=?select(list);
??...
}

不過，當(dāng) select 函數(shù)返回后，用戶依然需要遍歷剛剛提交給操作系統(tǒng)的 list。

只不過，操作系統(tǒng)會(huì)將準(zhǔn)備就緒的文件描述符做上標(biāo)識(shí)，用戶層將不會(huì)再有無意義的系統(tǒng)調(diào)用開銷。

while(1)?{
??nready?=?select(list);
??//?用戶層依然要遍歷，只不過少了很多無效的系統(tǒng)調(diào)用
??for(fd?<--?fdlist)?{
????if(fd?!=?-1)?{
??????//?只讀已就緒的文件描述符
??????read(fd,?buf);
??????//?總共只有?nready?個(gè)已就緒描述符，不用過多遍歷
??????if(--nready?==?0)?break;
????}
??}
}

正如剛剛的動(dòng)圖中所描述的，其直觀效果如下。（同一個(gè)動(dòng)圖消耗了你兩次流量，氣不氣？）

可以看出幾個(gè)細(xì)節(jié)：

整個(gè) select 的流程圖如下。

可以看到，這種方式，既做到了一個(gè)線程處理多個(gè)客戶端連接（文件描述符），又減少了系統(tǒng)調(diào)用的開銷（多個(gè)文件描述符只有一次 select 的系統(tǒng)調(diào)用 + n 次就緒狀態(tài)的文件描述符的 read 系統(tǒng)調(diào)用）。

poll

?

poll 也是操作系統(tǒng)提供的系統(tǒng)調(diào)用函數(shù)。

int?poll(struct?pollfd?*fds,?nfds_tnfds,?int?timeout);

struct?pollfd?{
??intfd;?/*文件描述符*/
??shortevents;?/*監(jiān)控的事件*/
??shortrevents;?/*監(jiān)控事件中滿足條件返回的事件*/
};

它和 select 的主要區(qū)別就是，去掉了 select 只能監(jiān)聽 1024 個(gè)文件描述符的限制。

?

epoll

?

epoll 是最終的大 boss，它解決了 select 和 poll 的一些問題。

還記得上面說的 select 的三個(gè)細(xì)節(jié)么？

所以 epoll 主要就是針對(duì)這三點(diǎn)進(jìn)行了改進(jìn)。

具體，操作系統(tǒng)提供了這三個(gè)函數(shù)。

第一步，創(chuàng)建一個(gè) epoll 句柄

int?epoll_create(int?size);

第二步，向內(nèi)核添加、修改或刪除要監(jiān)控的文件描述符。

int?epoll_ctl(
??int?epfd,?int?op,?int?fd,?struct?epoll_event?*event);

第三步，類似發(fā)起了 select() 調(diào)用

int?epoll_wait(
??int?epfd,?struct?epoll_event?*events,?int?max?events,?int?timeout);

使用起來，其內(nèi)部原理就像如下一般絲滑。

如果你想繼續(xù)深入了解 epoll 的底層原理，推薦閱讀飛哥的《圖解 | 深入揭秘 epoll 是如何實(shí)現(xiàn) IO 多路復(fù)用的！》，從 linux 源碼級(jí)別，一行一行非常硬核地解讀 epoll 的實(shí)現(xiàn)原理，且配有大量方便理解的圖片，非常適合源碼控的小伙伴閱讀。

后記

?