select,poll.epoll区别于联系

select，poll，epoll都是IO多路复用中的模型。再介绍他们特色时，先来看看多路复用的 模型。

同其余IO的不一样的是,IO多路复用一次能够等多个文件描述符。大大提升了等待数据准备好的时间的效率。为了完成等的效率，系统提供了三个系统调用：select，poll，epoll。这里再也不讲述三者具体实现，只总结三者的优缺点。

select的缺点

　　1.单个进程监控的文件描述符有限，一般为1024*8个文件描述符。固然能够改进，因为select采用轮询方式扫描文件描述符。文件描述符数量越多，性能越差。

　　2.内核/用户数据拷贝频繁，操做复杂。select在调用以前，须要手动在应用程序里将要监控的文件描述符添加到fed_set集合中。而后加载到内核进行监控。用户为了检测时间是否发生，还须要在用户程序手动维护一个数组，存储监控文件描述符。当内核事件发生，在将fed_set集合中没有发生的文件描述符清空，而后拷贝到用户区，和数组中的文件描述符进行比对。再调用selecct也是如此。每次调用，都须要了来回拷贝。

　　3.轮回时间效率低。select返回的是整个数组的句柄。应用程序须要遍历整个数组才知道谁发生了变化。轮询代价大。

　　四、select是水平触发。应用程序若是没有完成对一个已经就绪的文件描述符进行IO操做。那么以后select调用仍是会将这些文件描述符返回，通知进程。

poll特色
　　1.poll操做比select稍微简单点。select采用三个位图来表示fd_set，poll使用pollfd的指针，pollfd结构包含了要监视的event和发生的evevt，再也不使用select传值的方法。更方便

　　2.select的缺点依然存在。拿select为例，加入咱们的服务器须要支持100万的并发链接。则在FD_SETSIZE为1024的状况下，咱们须要开辟100个并发的进程才能实现并发链接。除了进程上下调度的时间消耗外。从内核到用户空间的无脑拷贝，数组轮询等，也是系统难以接受的。所以，基于select实现一个百万级别的并发访问是很难实现的。

epoll模型
　　因为epoll和上面的实现机制彻底不一样，因此上面的问题将在epoll中不存在。在select/poll中，服务器进程每次调用select都须要把这100万个链接告诉操做系统（从用户态拷贝到内核态）。让操做系统检测这些套接字是否有时间发生。轮询完以后，再将这些句柄数据复制到操做系统中，让服务器进程轮询处理已发生的网络时间。这一过程耗时耗力，而epoll经过在linux申请一个建议的文件系统，把select调用分为了三部分。

　　1）调用epoll_create创建一个epoll对象，这个对象包含了一个红黑树和一个双向链表。并与底层创建回调机制。
　　2）调用epoll_ctl向epoll对象中添加这100万个链接的套接字
　　3）调用epoll_wait收集发生事件的链接。

　　从上面的调用方式就能够看到epoll比select/poll的优越之处：由于后者每次调用时都要传递你所要监控的全部socket给select/poll系统调用，这意味着须要将用户态的socket列表copy到内核态，若是以万计的句柄会致使每次都要copy几十几百KB的内存到内核态，很是低效。而咱们调用epoll_wait时就至关于以往调用select/poll，可是这时却不用传递socket句柄给内核，由于内核已经在epoll_ctl中拿到了要监控的句柄列表。

　　因此，实际上在你调用epoll_create后，内核就已经在内核态开始准备帮你存储要监控的句柄了，每次调用epoll_ctl只是在往内核的数据结构里塞入新的socket句柄。

在内核里，一切皆文件。因此，epoll向内核注册了一个文件系统，用于存储上述的被监控socket。当你调用epoll_create时，就会在这个虚拟的epoll文件系统里建立一个file结点。固然这个file不是普通文件，它只服务于epoll。

　　epoll在被内核初始化时（操做系统启动），同时会开辟出epoll本身的内核高速cache区，用于安置每个咱们想监控的socket，这些socket会以红黑树的形式保存在内核cache里，以支持快速的查找、插入、删除。这个内核高速cache区，就是创建连续的物理内存页，而后在之上创建slab层，简单的说，就是物理上分配好你想要的size的内存对象，每次使用时都是使用空闲的已分配好的对象。

epoll的高效

　　epoll的高效就在于，当咱们调用epoll_ctl往里塞入百万个句柄时，epoll_wait仍然能够飞快的返回，并有效的将发生事件的句柄给咱们用户。这是因为咱们在调用epoll_create时，内核除了帮咱们在epoll文件系统里建了个file结点，在内核cache里建了个红黑树用于存储之后epoll_ctl传来的socket外，还会再创建一个list链表，用于存储准备就绪的事件，当epoll_wait调用时，仅仅观察这个list链表里有没有数据便可。有数据就返回，没有数据就sleep，等到timeout时间到后即便链表没数据也返回。因此，epoll_wait很是高效。并且，一般状况下即便咱们要监控百万计的句柄，大多一次也只返回不多量的准备就绪句柄而已，因此，epoll_wait仅须要从内核态copy少许的句柄到用户态而已，如何能不高效？！

就绪list链表维护
　　那么，这个准备就绪list链表是怎么维护的呢？当咱们执行epoll_ctl时，除了把socket放到epoll文件系统里file对象对应的红黑树上以外，还会给内核中断处理程序注册一个回调函数，告诉内核，若是这个句柄的中断到了，就把它放到准备就绪list链表里。因此，当一个socket上有数据到了，内核在把网卡上的数据copy到内核中后就来把socket插入到准备就绪链表里了。

如此，一颗红黑树，一张准备就绪句柄链表，少许的内核cache，就帮咱们解决了大并发下的socket处理问题。执行epoll_create时，建立了红黑树和就绪链表，执行epoll_ctl时，若是增长socket句柄，则检查在红黑树中是否存在，存在当即返回，不存在则添加到树干上，而后向内核注册回调函数，用于当中断事件来临时向准备就绪链表中插入数据。执行epoll_wait时马上返回准备就绪链表里的数据便可。

两种模式LT和ET

　　最后看看epoll独有的两种模式LT和ET。不管是LT和ET模式，都适用于以上所说的流程。区别是，LT模式下，只要一个句柄上的事件一次没有处理完，会在之后调用epoll_wait时次次返回这个句柄，而ET模式仅在第一次返回。

　　这件事怎么作到的呢？当一个socket句柄上有事件时，内核会把该句柄插入上面所说的准备就绪list链表，这时咱们调用epoll_wait，会把准备就绪的socket拷贝到用户态内存，而后清空准备就绪list链表，最后，epoll_wait干了件事，就是检查这些socket，若是不是ET模式（就是LT模式的句柄了），而且这些socket上确实有未处理的事件时，又把该句柄放回到刚刚清空的准备就绪链表了。因此，非ET的句柄，只要它上面还有事件，epoll_wait每次都会返回。而ET模式的句柄，除非有新中断到，即便socket上的事件没有处理完，也是不会次次从epoll_wait返回的。

其中涉及到的数据结构：

　　epoll用kmem_cache_create（slab分配器）分配内存用来存放struct epitem和struct eppoll_entry。

　　当向系统中添加一个fd时，就建立一个epitem结构体，这是内核管理epoll的基本数据结构：

struct epitem {
    struct rb_node rbn;          //用于主结构管理的红黑树
    struct list_head rdllink;    //事件就绪队列
    struct epitem *next;         //用于主结构体中的链表
    struct epoll_filefd ffd;     //这个结构体对应的被监听的文件描述符信息
    int nwait;                   //poll操做中事件的个数
    struct list_head pwqlist;    //双向链表，保存着被监视文件的等待队列，功能相似于select/poll中的poll_table
    struct eventpoll *ep;        //该项属于哪一个主结构体（多个epitm从属于一个eventpoll）
    struct list_head fllink;     //双向链表，用来连接被监视的文件描述符对应的struct file。由于file里有f_ep_link,用来保存全部监视这个文件的epoll节点
    struct epoll_event event;    //注册的感兴趣的事件,也就是用户空间的epoll_event
}

　　而每一个epoll fd（epfd）对应的主要数据结构为：

struct eventpoll {
spin_lock_t lock; //对本数据结构的访问
struct mutex mtx; //防止使用时被删除
wait_queue_head_t wq; //sys_epoll_wait()使用的等待队列
wait_queue_head_t poll_wait; //file->poll()使用的等待队列
struct list_head rdllist; //事件知足条件的链表 /*双链表中则存放着将要经过epoll_wait返回给用户的知足条件的事件*/
struct rb_root rbr; //用于管理全部fd的红黑树（树根）/*红黑树的根节点，这颗树中存储着全部添加到epoll中的须要监控的事件*/
struct epitem *ovflist; //将事件到达的fd进行连接起来发送至用户空间
}

　　struct eventpoll在epoll_create时建立。
　　这样说来，内核中维护了一棵红黑树，大体的结构以下：

 

 

 

　　总体而言：