要了解epoll模型，就要一个一个知识点由浅至深地去探索。
1.IO复用技术
IO流请求操作系统内核，有串行处理和并行处理两种概念。
串行处理是前面一个操作处理地时候，后面的所有操作都需要等待。因此，必须考虑以并行处理的方式来完成整个IO流的请求，实现最大的并发和吞吐。这里就用到了IO复用技术。
IO复用技术就是让一个Socket来做复用完成整个IO流的请求。实现IO流的请求其中一种方式就是多线程，但是多线程会占用大量资源，不便于管理，因此又出现了IO多路复用技术。
2.IO多路复用技术
IO多路复用是指多个描述符的I/O操作都能在一个线程内并发交替地顺序完成，这里的复用指的是复用同一个线程。
对操作系统内核而言，多路复用其实是要完成操作系统IO的请求，对于IO文件的请求，当一个IO流要进行对应的文件处理的时候，要获取一组文件的描述符，当文件描述符还没就绪的时候，它就一直在等待，直到描述符就绪，就马上上报系统的一个通知的机制，以此来告诉主应用程序它已经准备就绪了，你可以来操作了。这种方式就是IO多路复用方式。
3.IO多路复用技术的实现
IO多路复用技术的实现方式有select、poll和epoll，它们都是linux内核下的常见多路复用模型。
其中最早出现的是select模型。
4.select模型
多路复用其实就是内核态对IO请求的时候，会主动地发送所需要处理的文件对象就绪时文件的就绪信息给应用端，应用端在FD（File Description）没有就绪之前都是block，也就是阻塞对应的Socket请求，也会维护一个FD的列表。当内核态发送可用的信息，FD就绪之后，应用端采用select这种模式，会一直在遍历所维护的FD文件描述符的列表，以等到唤醒对应的线程完成对应的数据拷贝。select模型能够监视文件描述符的数量存在最大限制，且在整个过程中，select模型采用的是线性遍历的模式，这种模式效率低下。
5.epoll模型
epoll模型优化和完善了select模式的缺点，每当FD就绪，采用系统的回调函数直接将FD放入，效率高，无监视文件描述符的数量限制。
6.epoll模型的原理
设想一个场景：有100万用户同时与一个进程保持着TCP连接，而每一时刻只有几十个或几百个TCP连接是活跃的（接收到TCP包），也就是说，在每一时刻，进程只需要处理这100万个连接中的一小部分连接。那么，如何才能高效地处理这种场景呢？进程是否在每次询问操作系统收集有事件发生的TCP连接时，把这100万个连接告诉操作系统，然后由操作系统找出其中有事件发生的几百个连接呢？实际上，在Linux内核2.4版本之前，select或poll事件驱动模型就是这样处理的。
这里有个非常明显的问题，即在某一时刻，进程收集有事件的连接时，其实这100万连接中的大部分是没有事件发生的。因此，如果每次收集事件时，都把这100万连接的套接字传给操作系统（这首先就是用户态内存到内核态内存的大量复制），而由操作系统内核寻找这些连接上有没有未处理的事件，将会是巨大的资源浪费，然而select和poll就是这样做的，因此它们最多只能处理几千个并发连接。
而epoll就厉害了，它会在Linux内核中申请一个简易的文件系统，把原先的一个select或poll调用分成了3个部分：
1.调用epoll_create创建一个epoll对象（在epoll文件系统中给这个句柄分配资源，一棵红黑树和一个准备就绪list链表）。
2.调用epoll_ctl向epoll对象中添加这100万个连接的套接字。就是把socket放到红黑树上，给内核中断处理程序注册一个回调函数，然后告诉内核如果这个句柄的中断到了，就把这个socket放到准备就绪list链表里。
3.调用epoll_wait收集发生事件的TCP连接。到准备就绪list链表中处理socket，并把数据返回给用户。
这样，只需要在进程启动的时候建立1个epoll对象，并在需要的时候向它添加或删除连接即可。因此在实际收集事件时，epoll_wait的效率会非常高，因为调用epoll_wait时并没有向它传递这100万个连接，内核也不需要去遍历所有的连接，只需要到就绪list链表中去处理socket就行了。
"曾经以为拥有一点点可能的人，终究还是不可能。"