如何高效處理多個(gè)socket I/O的讀寫，是提高服務(wù)器性能的重點(diǎn)問(wèn)題。unix-like下面，現(xiàn)有機(jī)制有select,poll, epoll,kqueue,/dev/poll兩大類。
Select有個(gè)缺點(diǎn)，它用fd_set管理所有要監(jiān)視的I/O句柄，但是fd_set是一個(gè)位數(shù)組，只能接受句柄號(hào)小于FD_SETSIZE（默認(rèn)1024）的句柄，雖然進(jìn)程默認(rèn)句柄號(hào)都是小于1024的，但是可以通過(guò)ulimit –n來(lái)修改，尤其是連接數(shù)超過(guò)1024時(shí)必需這么做（實(shí)際可能更少），如果要將大于1024的句柄放入fd_set，就可能發(fā)生數(shù)組越界程序崩潰的場(chǎng)面。
Poll雖然解決了FD_SETSIZE問(wèn)題，但是它和select一樣，都有性能上的瓶頸。它們都會(huì)隨著連接數(shù)的增加性能直線下降。這主要有兩個(gè)原因，其一是每次select/poll操作，kernel都會(huì)建立一個(gè)當(dāng)前線程關(guān)心的事件列表，并讓線程阻塞在這個(gè)列表上，這是很耗時(shí)的操作。其二是每次select/poll返回后，線程都要掃描所有句柄來(lái)dispatch已發(fā)生的事件，這也是很耗時(shí)的。當(dāng)連接數(shù)巨大時(shí)，這種消耗積累起來(lái)，就很受不了。
為了解決select/poll的性能問(wèn)題，unix-like系統(tǒng)上開(kāi)發(fā)出了三套新的利器epoll，kqueue，/dev/poll，其中epoll是linux的，kqueue是freebsd的，/dev/poll是Solaris上的，它們是select/poll的替代品。它們的設(shè)計(jì)就是針對(duì)select/poll的性能問(wèn)題，主要避免 1。每次調(diào)用都建立事件等待列表，取而代之建立長(zhǎng)期的事件關(guān)注列表，這個(gè)列表可通過(guò)句柄（比如epfd）來(lái)增加和刪除事件。2。調(diào)用返回之后，不再需要遍歷所有句柄進(jìn)行分發(fā)，內(nèi)核會(huì)直接返回當(dāng)前已發(fā)生的事件。不用說(shuō)，性能在select, poll基礎(chǔ)上有了大幅提升。
要注意的是，凡是使用readiness notification（LT)或者readiness change notification（ET)機(jī)制，都應(yīng)該配合非阻塞I/O，因?yàn)檫@種事件通知，并不一定表示文件描述符真正就緒，如果收到通知之后去read，很有可能進(jìn)入阻塞狀態(tài)，這會(huì)嚴(yán)重影響服務(wù)器的并發(fā)性能，同時(shí)對(duì)ET模式，不能漏掉任何事件的處理，并且每次都應(yīng)該讀到socket返回EWOULDBLOCK為止，不然這個(gè)socket之后會(huì)永遠(yuǎn)保持沉默。