select、poll、epoll之间的区别

首先，select、poll、epoll是目前常用的三种IO复用模型，其次，什么是I/O复用？

IO复用：I/O复用就是单个线程通过记录跟踪每一个Sock(I/O流)的状态来同时管理多个I/O流.（具体的可以点进去看看）

现在对IO复用举个例子：

       比如一个教室中有二十名学生（客户端连接）和一名老师（负责数据交换的服务端），这些个学生会不定时的提问问题，但是这么多学生问问题，一名老师会应付不过来，所以学校就为每个学生分配了一名老师。（多进程的方式）

       但是学校聘请老师需要给人家发工资的啊，但是经费有限，所以学校决定聘请一个实力非凡具有超能力（简言之就是非常牛批）的老师，这个老师会负责回答所有的问题，但是相对于之前学生有问题直接向老师询问的方式，现在肯定不能这么办了吖，要不肯定会乱成一锅粥的，所以这个实力非凡的超能力老师也有自己的规矩，就是每个学生在提问之前必须先举手。那么现在的方式就是IO复用。

(1)select==>时间复杂度O(n)

通俗的说就是各个客户端连接的文件描述符也就是套接字，都会被放在一个集合中，调用select函数之后会一直监视着这些文件描述符中有哪些是需要读数据或者写入数据的，然后对他们进行操作，但是这样做的话有一个缺点：那就是它仅仅知道了有I/O事件发生了，去不知道是哪个流（一个或多个甚至没有），所以只能无差别轮询所有流，找出能读出数据，或者写入数据的流，对他们进行操作。

对于文件描述符解释一下：

      在Linux系统中一切皆可以看成是文件，文件又可分为：普通文件、目录文件、链接文件和设备文件。

      文件描述符（file descriptor）是内核为了高效管理已被打开的文件所创建的索引，其是一个非负整数（通常是小整数），用于指代被打开的文件，所有执行I/O操作(包括网络socket操作)的系统调用都通过文件描述符。

       所以我们也就可以知道：每个进程开启一个soeket连接，都会占用一个文件描述符。

select的缺点：

• 单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差；(在linux内核头文件中，有这样的定义：#define __FD_SETSIZE    1024)
• 内核 / 用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大的开销；
• select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；
• select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。 

(2)poll==>时间复杂度O(n)

        poll和select基本没有区别，本质上的不同是存放fd（文件描述符）集合的数据结构不同：相比较于select的集合，poll采用链表保存文件描述符，因此没有了监视文件数量的限制，但是select的其他的缺点poll依然存在。

        其次我们可以发现select和poll共有的一个缺点： 通过轮训的方式来查找是否可读或者可写，打个比方，如果同时有100万个连接都没有断开，而只有一个客户端发送了数据，所以这里它还是需要循环这么多次，造成资源浪费。

(3)epoll==>时间复杂度O(1)

        epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。把原先的select/poll调用分成了3个部分：

• 调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
• 调用epoll_ctl向epoll对象中添加这100万个连接的套接字
• 调用epoll_wait收集发生的事件的连接

        如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。

Linux内核具体的epoll机制实现思路

        当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体（红黑树，插入的时间效率是lgn，n为树的高度），所以每一个epoll对象都会拥有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件，这些事件都会挂载在红黑树中。

struct eventpoll{
    ....
    /*红黑树的根节点，这颗树中存储着所有添加到epoll中的需要监控的事件*/
    struct rb_root  rbr;
    /*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/
    struct list_head rdlist;
    ....
};

        而所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。

在epoll中，对于每一个事件，都会建立一个epitem结构体，如下所示

struct epitem{
    struct rb_node  rbn;//红黑树节点
    struct list_head    rdllink;//双向链表节点
    struct epoll_filefd  ffd;  //事件句柄信息
    struct eventpoll *ep;    //指向其所属的eventpoll对象
    struct epoll_event event; //期待发生的事件类型
}

        当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。

             epoll怎么实现的：通过红黑树和双链表数据结构，并结合回调机制

epoll的用法：

第一步：epoll_create()系统调用。此调用返回一个句柄，之后所有的使用都依靠这个句柄来标识。

第二步：epoll_ctl()系统调用。通过此调用向epoll对象中添加、删除、修改感兴趣的事件，返回0标识成功，返回-1表示失败。

第三部：epoll_wait()系统调用。通过此调用收集收集在epoll监控中已经发生的事件。