在I/O编程过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者I/O多路复用技术进行处理。I/O多路复用技术通过把多个I/O的阻塞复用到同一个select的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程／多进程模型相比，I/O多路复用的最大优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源，I/O多路复用的主要应用场景如下。
（1）服务器需要同时处理多个监听状态或者多个连接装套的套接字
（2）服务器需要同时处理多种网络协议的套接字
目前支持I/O多路复用的系统调用有select、pselect、poll、epoll，在Linux网络编程中，很长一段时间都使用select做轮询和网络事件通知，然而select的一些固有缺陷导致它的应用受到了很大的限制，最终Linux不得不在新的内核版本中寻找select的替代方案，最终选择了epoll。epoll与select的原理比较类似，为了克服select的缺点，epoll作了很多重大改进，现总结如下。
1、支持一个进程打开的socket描述符（FD）不受限制（仅受限于操作系统的最大文件句柄数）
select最大的缺陷就是单个进程所打开FD是有一定限制的，它由FD_SETSIZE设置，默认值是1024.对于那些需要支持上万个TCP连接的大型服务器来说显然太少了。可以选择修改这个宏然后重新编译内核，不过这会带来网络效率的下降。我们可以通过选择多进程的方案解决这个问题，不过虽然在Linux上创建进程的代价比较小，但仍旧是不可忽视的。另外，进程间的数据交换非常麻烦，对于Java来说，由于没有共享内存，需要通过Socket通信或者其他方式进行数据同步，这带来了额外的性能损耗，增加了程序复杂度，所以也不是一种完美的解决方案。值得庆幸的是，epoll并没有这个限制，它所支持的FD上限是操作系统的最大文件句柄数，这个数字远远大于1024.
2、I/O效率不会随着FD数目的增加而线性下降
传统select/poll的另一个致命弱点，就是当你拥有一个很大的socket集合时，由于网络延时或者链路空闲，任一时刻只有少部分的socket是“活跃”的，但是select/poll每次调用都会线性扫描全部的集合，导致效率呈线形下降。epoll不存在这个问题，它只会对“活跃”的socket进行操作—这是因为内核实现中，epoll是根据每个fd上面的callback函数实现的。那么，只有“活跃”的socket才会去主动调用callback函数，其他idle状态的socket则不会。在这点上，epoll实现了一个伪AIO。真对epoll和select性能对比的benchmark测试表明：如果所有的socket都处于活跃态—例如一个高速LAN环境，epoll并不比select/poll效率高太多；相反，如果过多使用epoll_ctl，效率相比还有稍微地降低。但是一旦使用idle connections模拟WAN环境，epoll的效率就远在select/poll之上了。
3、使用mmap加速内核与用户空间的消息传递
无论是select、poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存复制就显得非常重要，epoll是通过内核和用户空间mmap同一块内存来实现的。
4、epoll的API更简单
包括创建一个epoll描述符、添加监听事件、阻塞等待所监听的事件发生、关闭epoll描述符等。
值得说明的是，用来克服select/poll缺点的方法不只有epoll，epoll只是一种Linux的实现方案。在freeBSD下有kqueue，而dev/poll是一个古老的Solaris的方案，使用难度依次递增。kqueue是freebsd的宠儿，它实际上是一个功能相当丰富的kernel事件队列，它不仅仅是select/poll的升级，而且可以处理signal、目录结构变化、进程等多种事件。kqueue是边缘触发的。/dev/poll是Solaris的产物，是这一系列高性能API中最早出现的。Kernel提供了一个特殊的设备文件/dev/poll，应用程序打开这个文件得到操作fd_set的句柄，通过写入pollfd来修改它，一个特殊的ioctl调用用来替换select。不过由于出现的年代比较早，所以/dev/poll的接口实现比较原始。