Linux select/poll和epoll实现机制对比

关于这个话题，网上已经介绍的比较多，这里只是以流程图形式做一个简单明了的对比，方便区分。

一、select/poll实现机制

特点：

1.select/poll每次都需要重复传递全部的监听fd进来，涉及用户空间和内核直接的数据拷贝。

2.fd事件回调函数是pollwake，只是将本进程唤醒，本进程需要重新遍历全部的fd检查事件，然后保存事件，拷贝到用户空间，函数返回。

3.每次循环都是对全部的监测的fd进行轮询检测，可能发生事件的fd很少，这样效率很低。

4.当有事件发生，需要返回时，也需要将全部fd的事件进行返回，而其中可能只有很少的fd有事件发生。

5.select/poll返回时，会将该进程从全部监听的fd的等待队列里移除掉，这样就需要select/poll每次都要重新传入全部监听的fd，然后重新将本进程挂载到全部的监测fd的等待队列，大量重复劳动，效率很低。

参考链接：http://www.cnblogs.com/apprentice89/archive/2013/05/09/3070051.html

二、epoll实现机制

特点：

1.每次累加添加，不需要每次传入全部的监测fd。

2.每个fd只将本进程挂载到自己的等待队列一次，直到该fd被从epoll移除，不需要重复挂载。

3.fd事件回调函数是ep_epoll_callback，该函数将发生事件的fd加入到epoll专门的就绪队列rdllist中，同时唤醒本进程。

4.本进程不需要遍历每一个fd去监测事件是否发生，而只需要判断epoll中的就绪队列rdllist是否为空即可。

5.epoll返回时，只返回就绪队列rdllist中的项，避免了无关项的操作，应用层也就不需要再次重复遍历。

6.epoll内部使用红黑树存储监测fd，支持大量fd的快速查询、修改和删除操作。

epoll与select/poll机制的相同点：

1.主要监测流程是一样的，都需要将当前进程挂载到对应fd的队列中去。如果fd有事件发生，调用挂载的回调函数，该回调函数基本的作用是唤醒本进程。

2.主事件检测循环是一样的，循环检测是否有事件发生，有则处理事件后返回；没有则调用schedule_timeout睡眠一会。不同的是，select/poll直接检测每个fd，而epoll只需检测就绪队列rdllist是否有数据即可。

epoll针对select/poll的痛点进行的修改，也就是高效之处总结：

1. select/poll把fd的监听列表放在用户空间，由用户空间管理，导致在用户空间和内核空间之间频繁重复拷贝大量fd；epoll在内核建立fd监听列表（实际是红黑树），每次通过epoll_ctl增删改即可。

2. select/poll每当有fd内核事件时，都唤醒当前进程，然后遍历监听列表全部fd，检查所有就绪fd并返回；epoll在有fd内核事件时，通过回调把该fd放到就绪队列中，只需返回该就绪队列即可，不需要每次遍历全部监听fd。

参考链接：http://www.cnblogs.com/apprentice89/p/3234677.html

注：引用本人文章请注明出处，谢谢。