现在有这么一个场景：我是一个很忙的大老板，我有100个手机，手机来信息了，我的秘书就会告诉我“老板，你的手机来信息了。”我很生气，我的秘书就是这样子，每次手机来信息就只告诉我来信息了，老板赶紧去看。但是她从来不把话说清楚：到底是哪个手机来信息啊！我可有100个手机啊！于是，我只能一个一个手机去查看，来确定到底是哪几个手机来信息了。这就是IO复用中select模型的缺点！老板心想，要是秘书能把来信息的手机直接拿到我桌子上就好了，那么我的效率肯定大增（这就是epoll模型）。

那我们先来总结一下select模型的缺点：

  1. 单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差；(在linux内核头文件中，有这样的定义：#define __FD_SETSIZE 1024)

  2. 内核 / 用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大的开销；
    select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；

  3. select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。

设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？

粗略计算一下，一个进程最多有1024个文件描述符，那么我们需要开1000个进程来处理100万个客户连接。如果我们使用select模型，这1000个进程里某一段时间内只有数个客户连接需要数据的接收，那么我们就不得不轮询1024个文件描述符以确定究竟是哪个客户有数据可读，想想如果1000个进程都有类似的行为，那系统资源消耗可有多大啊！

针对select模型的缺点，epoll模型被提出来了！

epoll模型的优点