设想一个场景：有100万用户同一时候与一个进程保持着TCP连接，而每个时刻仅仅有几十个或几百个TCP连接时活跃的（接收到TCP包），也就是说，在每一时刻，进程值须要处理这100万连接中的一小部分连接。那么，怎样才干高效地处理这样的场景呢？进程是否在每次询问操作系统收集有事件发生的TCP连接时，把这100万个连接告诉操作系统，然后由操作系统找出当中有事件发生的几百个连接呢？实际上，在Linux内核2.4版本号曾经，那时的select或者poll事件驱动方式就是这样做的。

       这里有一个分厂明显的问题，即在某一时刻，进程收集有事件的连接时，事实上这100万连接中的大部分都是没有事件发生的。因此，假设每次收集事件时，都把这100万连接的套接字传给操作系统（这首先就是用户态内存到内核态内存的大量复制），而由操作系统内核寻找这些连接上有没有未处理的事件，将会是巨大的资源浪费，然而select和poll就是这样做的，因此他们最多仅仅能处理几千个并发连接。而epoll不这样做，他在linux内核中申请了一个简易的文件系统，把原先的一个select或者poll调用分成了3个部分：调用epoll_create建立1个epoll对象（在epoll文件系统中给这个句柄分配资源）、调用epoll_ctl向epoll对象中加入?这100万个连接的套接字、调用epoll_wati收集发生事件的连接。这样，仅仅须要在进程启动时建立1个epoll对象，并在须要的时候向它加入?或删除连接就能够了，因此，在实际收集事件时，epoll_wait的效率就会很高，由于调用epoll_wait时并没有向它传递着100万个连接，内核也不须要去遍历所有的连接。

      介绍epoll是怎么处理这样的情况的

     当某一个进程调用epoll_create方法时，linux内核会创建一个eventpoll结构体，这个结构体中有两个成员于epoll的使用方式密切相关，例如以下所看到的

     struct   eventpoll{

     /*红黑树的跟节点，这棵树中存储着全部加入?到epoll中的事件，也就是这个epoll监控的事件*/

      struct rb_root_rbr；

     //双向链表tdllist保存着将要通过epoll_wait放回给用户的、满足条件的事件

     struct  list_head_rdllist;

}

每个epoll对象都有一个独立的eventpoll结构体，这个结构体会在内核空间中创造独立的内存，用于存储使用epoll_ctl方法想epoll对象中加入?进来的事件。这些事件都会挂到rbr红黑树中，这样，反复加入?的事件就能够通过红黑树而高效标示出来（epoll_ctl方法会非常快）。

     全部加入?到epoll中的事件都会与设备（如网卡）驱动程序建立回调关系，也就是说，相应的事件发生时会调用这里的回调方法。这个回调方法在内核中叫做ep_epoll_callback，它会把这种事件放到上面的rdllist双向链表中。在epoll中，对于每个事件都会建立一个epitem结构体。这里包括每个事件相应着的信息。

      当调用epoll_wait检查是否有发生事件的连接时，仅仅是检查eventpoll对象中的rdllist双向链表是否有epitem元素而已，假设rdllist链表不为空，则把这里的事件拷贝到用户态内存中，同一时候将时间数量返回给用户，因此，epoll_wait的效率很高，epoll_ctl在向epoll对象中加入?、改动。删除事件时，从rbr红黑树中查找事件也很快，也就是说,epoll是很高效的，它能够轻易地处理百万级的并发连接。