深入理解NIO(四)—— epoll的实现原理
终于来到最后了,万里长征只差最后一步 ( `д´) !
简单流程梳理
我们先从只监听一个socket开始讲起:
首先我们有一个程序A,他运行这下面这样一段代码:
//创建socket
int s = socket(AF_INET, SOCK_STREAM, 0);//绑定端口
bind(s, ...)//监听
listen(s, ...)//接受客户端连接
int c =accept(s, ...)//接收客户端数据,没有数据就先阻塞在这里
recv(c, ...);//将数据打印出来
printf(...)
当程序A运行到recv()的时候它阻塞了,
之后就挂起在等待队列中,等待被唤醒之后继续执行,
而在Linux中,万事万物皆为文件,我们的socket也占用了一个fd。
我们的A就挂在socket中的等待队列中。
接下来我们来看一个简单的流程:
首先第一步是通过网线发送数据到网卡
网卡将数据存到内存中
网卡对cpu发出中断信号,提醒cpu过来处理网卡的任务
cpu接到信号后暂时中断自己的任务,过来运行网卡准备的中断程序
中断程序的内容是:将网卡写到内存中的网络数据写入socket的输入缓冲区
然后中断程序再唤醒处于阻塞状态的A唤醒,并挂到工作队列中让cpu运行它,而cpu就会运行刚刚代码的最后一段:打印
//将数据打印出来
printf(...)
当然,实际应用中我们不可能只监听一个socket,接下来我们就直接来看一下,能监听多个socket的select是怎么实现的:
select
select:上世纪 80 年代就实现了,它支持注册 FD_SETSIZE(1024) 个 socket,在那个年代肯定是够用的,不过现在嘛,肯定是不行了。
当然,这里的select不是指nio里的select()方法,而是指操作系统中的一个实现,它的改进版本是poll和epoll,请大家注意不要混淆。
我们先从select说起:
int s = socket(AF_INET, SOCK_STREAM, 0);
bind(s, ...);
listen(s, ...);int fds[] = //存放需要监听的socket;
while(1){//这里就是我们的select
int n = select(..., fds, ...)for(int i=0; i < fds.count; i++){if(FD_ISSET(fds[i], ...)){//fds[i]的数据处理
}
}
}
这段代码中,先准备了一个数组 fds,让 fds 存放着所有需要监视的 socket。然后调用 select,如果 fds 中的所有 socket 都没有数据,select 会阻塞,直到有一个 socket 接收到数据,select 返回,唤醒进程。用户可以遍历 fds,通过 FD_ISSET 判断具体哪个 socket 收到数据,然后做出处理。
接下来我们看一下流程图:
流程基本都一样,A却存在于多个socket的等待队列中
当某个socket被写入数据时,A也被唤醒并从多个socket的等待队列中移除后加入工作队列
但是此时A并不知道是哪个socket被写入了数据,所以只能遍历所有socket
在A处理完任务后移出工作队列,但是此时却需要遍历所有socket并加入它们的等待队列中
select的缺点在于:
每次调用 select 都需要将进程加入到所有监视 socket 的等待队列,每次唤醒都需要从每个队列中移除。这里涉及了两次遍历,而且每次都要将整个 fds 列表传递给内核,有一定的开销。正是因为遍历操作开销大,出于效率的考量,才会规定 select 的最大监视数量,默认只能监视 1024 个 socket。
进程被唤醒后,程序并不知道哪些 socket 收到数据,还需要遍历一次。
poll
因此人们先提出了poll
poll:1997 年,出现了 poll 作为 select 的替代者,最大的区别就是,poll 不再限制 socket 数量。
但是poll并没有解决刚刚提到的select的问题,所以就有了epoll
epoll
select 低效的原因之一是将“维护等待队列”和“阻塞进程”两个步骤合二为一。如下图所示,每次调用 select 都需要这两步操作,然而大多数应用场景中,需要监视的 socket 相对固定,并不需要每次都修改。epoll 将这两个操作分开,先用 epoll_ctl 维护等待队列,再调用 epoll_wait 阻塞进程。显而易见地,效率就能得到提升。
还记得我们的NIO源码分析吗,里面就调用了epoll_create、epoll_ctl和epoll_wait
epoll_create
当某个进程调用 epoll_create 方法时,内核会创建一个 eventpoll 对象(也就是程序中 epfd 所代表的对象)。eventpoll 对象也是文件系统中的一员,和 socket 一样,它也会有等待队列。
epoll_ctl
如果通过 epoll_ctl 添加 sock1、sock2 和 sock3 的监视,内核会将 eventpoll 添加到这三个 socket 的等待队列中。
epoll_wait
进程 A 运行到了 epoll_wait 语句。如下图所示,内核会将进程 A 放入 eventpoll 的等待队列中,阻塞进程。(这里的rdlist和等待队列都是eventpoll对象的属性一样的东西,都是属于它的)
当 socket 接收到数据,中断程序一方面修改 rdlist,另一方面唤醒 eventpoll 等待队列中的进程,进程 A 再次进入运行状态(如下图)。也因为 rdlist 的存在,进程 A 可以知道哪些 socket 发生了变化。
数据结构
监听所有socket的等待队列(不是存放进程A的)的结构是红黑树,红黑树是一种自平衡二叉查找树,搜索、插入和删除时间复杂度都是O(log(N)),效率较好
而rdlist是一个双向链表,进程A应该是放在poll_wait里(我猜的,错了不怪我)
Linux epoll API
之前说Java NIO封装了epoll的api,那么我们就来看一下它的api吧(虽然并不重要,但是还是看看吧):
int epoll_create(int size)
创建一个epoll的句柄。自从linux2.6.8之后,size参数是被忽略的。需要注意的是,当创建好epoll句柄后,它就是会占用一个fd值,在linux下如果查看/proc/进程id/fd/,是能够看到这个fd的,所以在使用完epoll后,必须调用close()关闭,否则可能导致fd被耗尽。
int epoll_ctl(int epfd, int op, int fd, struct epoll_event*event)
1. 第一个参数是epoll_create()的返回值。
2. 第二个参数表示动作,用三个宏来表示:
EPOLL_CTL_ADD:注册新的fd到epfd中;
EPOLL_CTL_MOD:修改已经注册的fd的监听事件;
EPOLL_CTL_DEL:从epfd中删除一个fd;
3. 第三个参数是需要监听的fd。
4. 第四个参数是告诉内核需要监听什么事:
EPOLLIN :表示对应的文件描述符可以读(包括对端SOCKET正常关闭);
EPOLLOUT:表示对应的文件描述符可以写;
EPOLLPRI:表示对应的文件描述符有紧急的数据可读(这里应该表示有带外数据到来);
EPOLLERR:表示对应的文件描述符发生错误;
EPOLLHUP:表示对应的文件描述符被挂断;
EPOLLET: 将EPOLL设为边缘触发(Edge Triggered)模式,这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT:只监听一次事件,当监听完这次事件之后,如果还需要继续监听这个socket的话,需要再次把这个socket加入到EPOLL队列里
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout)
收集在epoll监控的事件中已经发送的事件。
参数events是分配好的epoll_event结构体数组,epoll将会把发生的事件赋值到events数组中(events不可以是空指针,内核只负责把数据复制到这个events数组中,不会去帮助我们在用户态中分配内存)。
maxevents告之内核这个events有多大,这个maxevents的值不能大于创建epoll_create()时的size。
参数timeout是超时时间(毫秒,0会立即返回,-1是永久阻塞)。如果函数调用成功,返回对应I/O上已准备好的文件描述符数目,如返回0表示已超时。
epoll的两种触发模式
epoll有EPOLLLT和EPOLLET两种触发模式,LT是默认的模式,ET是“高速”模式。
LT(水平触发)模式下,只要这个文件描述符还有数据可读,每次 epoll_wait都会返回它的事件,提醒用户程序去操作;
ET(边缘触发)模式下,在它检测到有 I/O 事件时,通过 epoll_wait 调用会得到有事件通知的文件描述符,对于每一个被通知的文件描述符,如可读,则必须将该文件描述符一直读到空,让 errno 返回 EAGAIN 为止,否则下次的 epoll_wait 不会返回余下的数据,会丢掉事件。如果ET模式不是非阻塞的,那这个一直读或一直写势必会在最后一次阻塞。
采用ET这种边缘触发模式的话,当被监控的文件描述符上有可读写事件发生时,epoll_wait()会通知处理程序去读写。如果这次没有把数据全部读写完(如读写缓冲区太小),那么下次调用epoll_wait()时,它不会通知你,也就是它只会通知你一次,直到该文件描述符上出现第二次可读写事件才会通知你
如果你能看到这里
终于结束了 ( `д´) !经过四篇深入理解NIO系列博文,你已经是个成熟Java调包师了,你将和我一样找不到工作,おめでとう !