详解IO多路复用中的select, poll, epoll

select, poll, epoll 都是I/O多路复用的具体的实现，这三个是不同时期先后顺序出来的，也是为了改进性能。

I/O多路复用这个概念被提出来以后， select是第一个实现 (1983 左右在BSD里面实现的)。

1.select 被实现以后，暴露出了很多问题。

• select 会修改传入的参数数组，这个对于一个需要调用很多次的函数，是非常不友好的。
• select 如果任何一个sock(I/O stream)出现了数据，select 仅仅会返回，但是并不会告诉你是哪个sock上有数据，于是你只能自己一个一个的找，10几个sock可能还好，要是几万的sock每次都找一遍，这就消耗了很多无谓开销。
• select 只能监视1024个链接， linux 定义在头文件中的，参见FD_SETSIZE。
• select 不是线程安全的，如果你把一个sock加入到select, 然后突然另外一个线程发现，这个sock不用，要收回。这时候这个select 不支持的，如果你强制关掉这个sock，结果不可预测的。

2.poll的诞生：于是14年以后(1997年）一帮人又实现了poll, poll 修复了select的很多问题，比如：

• poll 去掉了1024个链接的限制，于是要多少链接呢， 自己随意设置。
• poll 从设计上来说，可以不再修改传入数组，当然这个要看你的平台了。

但是poll仍然不是线程安全的， 这就意味着，不管服务器有多强悍，你也只能在一个线程里面处理一组I/O流。你当然可以拿多进程来配合了，不过就有了多进程的各种问题。

3.于是5年以后, 在2002, 大神 Davide Libenzi 实现了epoll

epoll 可以说是I/O 多路复用最新的一个实现，epoll 修复了poll 和select绝大部分问题, 比如：

• epoll 现在是线程安全的。
• epoll 现在不仅告诉你sock组里面数据，还会告诉你具体哪个sock有数据，你不用自己去找了。

可是epoll 有个致命的缺点，就是只有linux支持。比如BSD上面对应的实现是kqueue。

nginx就是使用的epoll