io多路复用：select、poll和epoll

1、为什么使用多路复用：

1.1单线程BIO监听socket

多路复用一般用于网络io当中，提到网络io我们肯定能想到socket。如果我们想要一个线程单纯的用向下文的方式监听很多个socket看他是否有事件发生，那这样是不可行。

但上一个socket1没有可读事件时会阻塞，则此时socket2有可读事件也无法读取到。

1.2多线程监听socket

如果使用多线程监听socket的话，每来一个连接就创建一个新的线程，那这种方法光听着就效率低下，因为线程之间的切换是要消耗资源的。线程过多导致线程切换频繁，效率低。

1.3多路复用机制的诞生

多路复用其实就是使用一个线程监听多个socket，那为什么现在不会出现前面讲的那个单线程问题呢，因为现在这个线程只是监听是否有io事件发生，并不真正的进行读取。再Linux系统中每一个socket就是一个文件，每个文件由唯一一个文件描述符表示。当这个多路复用器想要监听放入到一个集合当中，当有事件发生时会将有事件发生的文件描述符特殊标记，表示它有事件发生，然后再将这个io事件分发给真正做事的线程去完成。所以复用是复用再事件的检测方面。让事件检测和事件处理进行解耦。

2、多路复用器的类别及说明

多路复用器有三中，分别为select、poll和epoll。现在大部分使用的都是epoll。如redis使用的就是epoll。

2.1 select（假设只检测可读事件）：

select实现多路复用的方式就是想要监听的Socket放入到一个fds(文件描述符集合)当中。它会先把这个集合拷贝到内核空间当中，然后遍历fds看看里面有没有可读事件，如果没有的话会进行阻塞，直至有可读事件发生，当有可读事件发生时(超过超时时间也会停止阻塞)，线程会被唤醒并再遍历一遍将可读事件给进行标记。此时将这个集合再次拷贝从内核到用户态。然后用户监听要再次遍历这个集合将其有可读事件的socket找出来然后仍给工作线程进行处理。

select使用的时固定长度的BitsMap来作为fds。所以说它可监听的socket是有限制的，在Liunx当中默认最多监听1024个socket文件。

从上面的描述当中我们可以看到select有着一些明显的缺点。例如：它使用的是固定长度的BItsMap来作为fds，导致所监听的socket文件数量有限制。还有我们可以看到这个监听的过程中有着两次的fds的拷贝，当次数、数量多起来后这也是性能的一大痛点。还有他对于查询有可读事件的时候要线性遍历fds，返回到用户态时用户还得再次线性遍历一次，查出哪些具有可读状态。

2.2poll

poll其实和select没有太大的区别，它两唯一大的区别就是poll改用动态数组来作为fds(文件描述符集合)。这样就解决了select在监听数量上的限制了，但在效率方面并没有改进，还是需要进行拷贝和线性遍历。

2.3 epoll（相较于前两个效率有了很大的提升）

这个就是epoll的结构。首先我们需要使用epoll_create方法在内核当中创建epoll对象。再epoll对象中有一个红黑树。这个红黑树的作用就相当于fds(文件描述符集合)。再这颗树上存着要检测的socket文件。再之前的select/poll中是没有再内核中专门创建存放fds的空间的，导致每次调用都要将fds拷贝一遍到内核当中。而此时epoll使用红黑树将fds一直存在内核当中，不再需要每次进行拷贝，当需要增加新的带检测的socket时直接调用epoll_ctl进行添加就行，时间复杂度为（logn）。

对于事件的检测epoll使用了事件驱动，也就是当某个socket有事件发生时，内核会有回调方法将其加入到就绪队列当中。这个就绪队列就是记录被检测socket中有事件发生的socke。此时我们不需要进行遍历所有socket查询是哪个socket具有事件。

当我们调用epoll_waitl方法时，它的第二个参数是一个epoll_even结构数组指针，当有就绪链表不为空时，就会将链表链表复制到这个数组当中，返回值为一个数值，表示有多少个事件发生。此时可以通过操作这个数组直接进行数值处理，不用遍历一整个fds。

3、总结

select，poll，epoll都是IO多路复用机制，即可以监视多个描述符，一旦某个描述符就绪（读或写就绪），能够通知程序进行相应读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。