首先我们要明确一点：select, poll, epoll本质上都是同步的I/O，因为它们都是在读写事件就绪后自己负责进行读写，这个读写的过程是阻塞的。select, poll, epoll 都是一种 I/O 复用的机制。它们都是通过一种机制（由系统提供的）来监视多个描述符，一旦某个描述符就绪了，就能通知程序进行相应的读写操作。
那什么是I/O复用呢？I/O复用就是一种进程预先告知内核的能力，使得内核一旦发现进程指定的一个或多个I/O条件就绪，它就通知进程。
Linux下有五种I/O模型，分别是 阻塞式I/O、非阻塞式I/O、I/O复用、信号驱动式I/O、异步I/O。
阻塞式I/O，即应用程序调用IO函数，导致程序阻塞（当前进程被挂起，暂停运行直到函数返回），等待数据准备好，如果数据没有准备好，进程就一直处于等待状态，只有数据准备好了且返回到进程缓冲区或发生错误才返回。在网络通信中，socket函数创建套接字时，所有的套接字默认都是阻塞的。
非阻塞式I/O，进程反复调用一个IO函数，若没有数据准备好，返回一个错误，即不进入阻塞状态，而是不断的进行函数调用。 把一个SOCKET接口设置为非阻塞就是告诉内核，当所请求的I/O操作无法完成时，不要将进程睡眠，而是返回一个错误。这样我们的I/O操作函数将不断的测试数据是否已经准备好，如果没有准备好，继续测试，直到数据准备好为止。在这个不断测试的过程中，会大量的占用CPU的时间。
I/O复用，主要通过select和poll等函数来实现，阻塞在这两个系统调用中的某一个之上，而不是阻塞在真正的IO系统调用上，比阻塞IO并没有什么优越性；关键是能实现同时对多个IO端口进行监听（select和poll等函数可以看作是一种代理，由它们来代替IO函数进行监听等待）。
信号驱动式I/O，通过使用信号，让内核在描述符就绪时发送SIGIO信号给进程。当程序运行到IO时，进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，可以在信号处理函数中调用I/O操作函数处理数据。
异步I/O，提前告知内核执行某个操作，且在内核完成整个操作之后通过我们，在等待IO执行期间，进程不会阻塞。
总结：同步IO引起进程阻塞，直至IO操作完成。
异步IO不会引起进程阻塞。
IO复用是先通过select调用阻塞。
1、select
select 是通过系统调用来监视着一个由多个文件描述符（file descriptor）组成的数组，当select()返回后，数组中就绪的文件描述符会被内核修改标记位(其实就是一个整数)，使得进程可以获得这些文件描述符从而进行后续的读写操作。select饰通过遍历来监视整个数组的，而且每次遍历都是线性的。select函数允许进程指示内核等待多个事件中的一个或多个发生，并只在有一个或多个事件发生或经历一段指定的时间后才唤醒它。我们调用select告知内核对哪些描述字（就读、写或异常条件）感兴趣以及等待多长时间。我们感兴趣的描述字不局限于套接口，任何描述字都可以使用select来测试。
select缺点：
- 每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多的时候会很大
- 单个进程能够监视的fd数量存在最大限制，在linux上默认为1024（可以通过修改宏定义或者重新编译内核的方式提升这个限制）
- 并且由于select的fd是放在数组中，并且每次都要线性遍历整个数组，当fd很多的时候，开销也很大
2、poll
poll函数提供的功能与select类似，不过在处理流设备时，它能够额外的信息，只是没有了最大连接数(linux上默认1024个)的限制，原因是它基于链表存储的。poll除了没有了最大连接数的缺点，其他都和select一样。
3、epoll
在linux2.6（准确来说是2.5.44）由内核直接支持的方法。epoll解决了select和poll的缺点。
- 对于第一个缺点，epoll的解决方法是每次注册新的事件到epoll中，会把所有的fd拷贝进内核，而不是在等待的时候重复拷贝，保证了每个fd在整个过程中只会拷贝1次。
- 对于第二个缺点，epoll没有这个限制，它所支持的fd上限是最大可以打开文件的数目，具体数目可以cat /proc/sys/fs/file-max查看，一般来说这个数目和系统内存关系比较大。
- 对于第三个缺点，epoll的解决方法不像select和poll每次对所有fd进行遍历轮询所有fd集合，而是在注册新的事件时，为每个fd指定一个回调函数，当设备就绪的时候，调用这个回调函数，这个回调函数就会把就绪的fd加入一个就绪表中。（所以epoll实际只需要遍历就绪表）。
epoll同时支持水平触发和边缘触发：
- 水平触发（level－triggered）：只要满足条件，就触发一个事件(只要有数据没有被获取，内核就不断通知你)。e.g:在水平触发模式下，重复调用
epoll.poll()会重复通知关注的event，直到与该event有关的所有数据都已被处理。(select, poll是水平触发, epoll默认水平触发) - 边缘触发（edge－triggered）：每当状态变化时，触发一个事件。e.g:在边沿触发模式中，epoll.poll()在读或者写event在socket上面发生后，将只会返回一次event。调用
epoll.poll()的程序必须处理所有和这个event相关的数据，随后的epoll.poll()调用不会再有这个event的通知。
select、poll、epoll区别：
poll的实现和select非常相似，只是描述fd集合的方式不同，poll使用pollfd结构而不是select的fd_set结构，其他的都差不多。epoll的解决方案在epoll_ctl函数中。每次注册新的事件到epoll句柄中时（在epoll_ctl中指定EPOLL_CTL_ADD），会把所有的fd拷贝进内核，而不是在epoll_wait的时候重复拷贝。epoll保证了每个fd在整个过程中只会拷贝一次。
epoll的解决方案不像select或poll一样每次都把current轮流加入fd对应的设备等待队列中，而只在epoll_ctl时把current挂一遍（这一遍必不可少）并为每个fd指定一个回调函数，当设备就绪，唤醒等待队列上的等待者时，就会调用这个回调函数，而这个回调函数会把就绪的fd加入一个就绪链表）。epoll_wait的工作实际上就是在这个就绪链表中查看有没有就绪的fd（利用schedule_timeout()实现睡一会，判断一会的效果，和select实现中的第7步是类似的）。
对于poll的第三个缺点，epoll没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048。
select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。
select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。epoll的最大好处是不会随着FD的数目增长而降低效率，在selec中采用轮询处理，其中的数据结构类似一个数组的数据结构，而epoll是维护一个队列，直接看队列是不是空就可以了。epoll只会对”活跃”的socket进行操作—这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有”活跃”的socket才会主动的去调用 callback函数（把这个句柄加入队列），其他idle状态句柄则不会，在这点上，epoll实现了一个”伪”AIO。但是如果绝大部分的I/O都是“活跃的”，每个I/O端口使用率很高的话，epoll效率不一定比select高（可能是要维护队列复杂）。