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的实现会负责把数据从内核拷贝到用户空间。