參考面試官：簡單說一下阻塞IO、非阻塞IO、IO復(fù)用的區(qū)別 ？_unix環(huán)境編程 阻塞io和非阻塞io-CSDN博客

同步阻塞(BIO)

BIO 以流的方式處理數(shù)據(jù)

應(yīng)用程序發(fā)起一個系統(tǒng)調(diào)用（recvform），這個時候應(yīng)用程序會一直阻塞下去，直到內(nèi)核把數(shù)據(jù)準(zhǔn)備好，并將其從內(nèi)核復(fù)制到用戶空間，復(fù)制完成后返回成功提示，這個時候應(yīng)用程序才會繼續(xù)處理數(shù)據(jù)。

服務(wù)實(shí)現(xiàn)模式為一個連接對應(yīng)一個線程，即客戶端發(fā)送一個連接，服務(wù)端要有一個線程來處理。

• 缺點(diǎn)

? ? ? ? 一旦有高并發(fā)的大量請求,就會有如下問題： 1）線程不夠用，就算使用了線程池復(fù)用線程也無濟(jì)于事(一臺機(jī)器需要維護(hù) 1 萬個連接，相當(dāng)于要維護(hù) 1 萬個進(jìn)程/線程，操作系統(tǒng)就算死扛也是扛不住的)；2）阻塞I/O模式下，會有大量的線程被阻塞，一直在等待數(shù)據(jù),這個時候的線程被掛起，只能干等，CPU利用率很低，換句話說，系統(tǒng)的吞吐量差；3）如果網(wǎng)絡(luò)I/O堵塞或者有網(wǎng)絡(luò)抖動或者網(wǎng)絡(luò)故障等，線程的阻塞時間可能很長，整個系統(tǒng)也變的不可靠；4）服務(wù)器線程太多，壓力太大，導(dǎo)致服務(wù)器宕機(jī)。

同步非阻塞(NIO)

NIO 以緩沖區(qū)的方式處理數(shù)據(jù),緩沖區(qū) I/O 的效率比流 I/O 高很多

應(yīng)用進(jìn)程需要不斷詢問內(nèi)核數(shù)據(jù)是否就緒，在內(nèi)核數(shù)據(jù)還未就緒時，應(yīng)用進(jìn)程還可以做其他事情。

服務(wù)實(shí)現(xiàn)模式是一個線程可以處理多個連接，即客戶端發(fā)送的連接都會注冊到多路復(fù)用器上，然后進(jìn)行輪詢連接，有I/O請求就處理。

• 優(yōu)點(diǎn):模型簡單，實(shí)現(xiàn)難度低;與阻塞IO模型對比，它在等待數(shù)據(jù)報的過程中，進(jìn)程并沒有阻塞，它可以做其他的事情。

• 缺點(diǎn):輪詢發(fā)送 recvform，消耗CPU 資源。

I/O多路復(fù)用

在沒有使用IO多路復(fù)用機(jī)制時，有BIO、NIO兩種實(shí)現(xiàn)方式，但是會出現(xiàn)阻塞或者開銷大的問題

參考這次答應(yīng)我，一舉拿下 I/O 多路復(fù)用！ (qq.com)

非阻塞IO模型需要進(jìn)程不斷地輪詢發(fā)起recvform系統(tǒng)調(diào)用，就會有很多的線程不斷調(diào)用recvfrom 請求數(shù)據(jù)，先不說服務(wù)器能不能扛得住這么多線程，就算扛得住那么很明顯這種方式是不是太浪費(fèi)資源了，線程是我們操作系統(tǒng)的寶貴資源，大量的線程用來去讀取數(shù)據(jù)了，那么就意味著能做其它事情的線程就會少。

select/poll/epoll 這是三個多路復(fù)用接口，都能實(shí)現(xiàn) C10K 嗎？接下來，我們分別說說它們。

select/poll

select 實(shí)現(xiàn)多路復(fù)用的方式是，將已連接的 Socket 都放到一個文件描述符集合，然后調(diào)用 select 函數(shù)將文件描述符集合拷貝到內(nèi)核里，讓內(nèi)核來檢查是否有網(wǎng)絡(luò)事件產(chǎn)生，檢查的方式很粗暴，就是通過遍歷文件描述符集合的方式，當(dāng)檢查到有事件產(chǎn)生后，將此 Socket 標(biāo)記為可讀或可寫， 接著再把整個文件描述符集合拷貝回用戶態(tài)里，然后用戶態(tài)還需要再通過遍歷的方法找到可讀或可寫的 Socket，然后再對其處理。

所以，對于 select 這種方式，需要進(jìn)行?2 次「遍歷」文件描述符集合，一次是在內(nèi)核態(tài)里，一個次是在用戶態(tài)里 ，而且還會發(fā)生?2 次「拷貝」文件描述符集合，先從用戶空間傳入內(nèi)核空間，由內(nèi)核修改后，再傳出到用戶空間中。

select 使用固定長度的 BitsMap，表示文件描述符集合，而且所支持的文件描述符的個數(shù)是有限制的，在 Linux 系統(tǒng)中，由內(nèi)核中的 FD_SETSIZE 限制， 默認(rèn)最大值為?1024，只能監(jiān)聽 0~1023 的文件描述符。

poll 不再用 BitsMap 來存儲所關(guān)注的文件描述符，取而代之用動態(tài)數(shù)組，以鏈表形式來組織，突破了 select 的文件描述符個數(shù)限制，當(dāng)然還會受到系統(tǒng)文件描述符限制。

但是 poll 和 select 并沒有太大的本質(zhì)區(qū)別，都是使用「線性結(jié)構(gòu)」存儲進(jìn)程關(guān)注的 Socket 集合，因此都需要遍歷文件描述符集合來找到可讀或可寫的 Socket，時間復(fù)雜度為 O(n)，而且也需要在用戶態(tài)與內(nèi)核態(tài)之間拷貝文件描述符集合，這種方式隨著并發(fā)數(shù)上來，性能的損耗會呈指數(shù)級增長。

epoll

epoll 通過兩個方面，很好解決了 select/poll 的問題。

第一點(diǎn)，epoll 在內(nèi)核里使用紅黑樹來跟蹤進(jìn)程所有待檢測的文件描述字，把需要監(jiān)控的 socket 通過epoll_ctl()函數(shù)加入內(nèi)核中的紅黑樹里，紅黑樹是個高效的數(shù)據(jù)結(jié)構(gòu)，增刪查一般時間復(fù)雜度是O(logn)，通過對這棵黑紅樹進(jìn)行操作，這樣就不需要像 select/poll 每次操作時都傳入整個 socket 集合，只需要傳入一個待檢測的 socket，減少了內(nèi)核和用戶空間大量的數(shù)據(jù)拷貝和內(nèi)存分配。

第二點(diǎn)， epoll 使用事件驅(qū)動的機(jī)制，內(nèi)核里維護(hù)了一個鏈表來記錄就緒事件，當(dāng)某個 socket 有事件發(fā)生時，通過回調(diào)函數(shù)內(nèi)核會將其加入到這個就緒事件列表中，當(dāng)用戶調(diào)用epoll_wait()函數(shù)時，只會返回有事件發(fā)生的文件描述符集合，不需要像 select/poll 那樣輪詢掃描整個 socket 集合，大大提高了檢測的效率。

從下圖你可以看到 epoll 相關(guān)的接口作用：

?

epoll 的方式即使監(jiān)聽的 Socket 數(shù)量越多的時候，效率不會大幅度降低，能夠同時監(jiān)聽的 Socket 的數(shù)目也非常的多了，上限就為系統(tǒng)定義的進(jìn)程打開的最大文件描述符個數(shù)。因而，epoll 被稱為解決 C10K 問題的利器。

epoll 支持兩種事件觸發(fā)模式，分別是邊緣觸發(fā)（edge-triggered，ET）和水平觸發(fā)（level-triggered，LT）。

這兩個術(shù)語還挺抽象的，其實(shí)它們的區(qū)別還是很好理解的。

• 使用邊緣觸發(fā)模式時，當(dāng)被監(jiān)控的 Socket 描述符上有可讀事件發(fā)生時，服務(wù)器端只會從 epoll_wait 中蘇醒一次，即使進(jìn)程沒有調(diào)用 read 函數(shù)從內(nèi)核讀取數(shù)據(jù)，也依然只蘇醒一次，因此我們程序要保證一次性將內(nèi)核緩沖區(qū)的數(shù)據(jù)讀取完；

• 使用水平觸發(fā)模式時，當(dāng)被監(jiān)控的 Socket 上有可讀事件發(fā)生時，服務(wù)器端不斷地從 epoll_wait 中蘇醒，直到內(nèi)核緩沖區(qū)數(shù)據(jù)被 read 函數(shù)讀完才結(jié)束，目的是告訴我們有數(shù)據(jù)需要讀取；

舉個例子，你的快遞被放到了一個快遞箱里，如果快遞箱只會通過短信通知你一次，即使你一直沒有去取，它也不會再發(fā)送第二條短信提醒你，這個方式就是邊緣觸發(fā)；如果快遞箱發(fā)現(xiàn)你的快遞沒有被取出，它就會不停地發(fā)短信通知你，直到你取出了快遞，它才消停，這個就是水平觸發(fā)的方式。

這就是兩者的區(qū)別，水平觸發(fā)的意思是只要滿足事件的條件，比如內(nèi)核中有數(shù)據(jù)需要讀，就一直不斷地把這個事件傳遞給用戶；而邊緣觸發(fā)的意思是只有第一次滿足條件的時候才觸發(fā)，之后就不會再傳遞同樣的事件了。

如果使用水平觸發(fā)模式，當(dāng)內(nèi)核通知文件描述符可讀寫時，接下來還可以繼續(xù)去檢測它的狀態(tài)，看它是否依然可讀或可寫。所以在收到通知后，沒必要一次執(zhí)行盡可能多的讀寫操作。

如果使用邊緣觸發(fā)模式，I/O 事件發(fā)生時只會通知一次，而且我們不知道到底能讀寫多少數(shù)據(jù)，所以在收到通知后應(yīng)盡可能地讀寫數(shù)據(jù)，以免錯失讀寫的機(jī)會。因此，我們會循環(huán)從文件描述符讀寫數(shù)據(jù)，那么如果文件描述符是阻塞的，沒有數(shù)據(jù)可讀寫時，進(jìn)程會阻塞在讀寫函數(shù)那里，程序就沒辦法繼續(xù)往下執(zhí)行。所以，邊緣觸發(fā)模式一般和非阻塞 I/O 搭配使用，程序會一直執(zhí)行 I/O 操作，直到系統(tǒng)調(diào)用（如?read?和?write）返回錯誤，錯誤類型為?EAGAIN?或?EWOULDBLOCK。

一般來說，邊緣觸發(fā)的效率比水平觸發(fā)的效率要高，因?yàn)檫吘売|發(fā)可以減少 epoll_wait 的系統(tǒng)調(diào)用次數(shù)，系統(tǒng)調(diào)用也是有一定的開銷的的，畢竟也存在上下文的切換。

select/poll 只有水平觸發(fā)模式，epoll 默認(rèn)的觸發(fā)模式是水平觸發(fā)，但是可以根據(jù)應(yīng)用場景設(shè)置為邊緣觸發(fā)模式。