深入理解NIO（四）—— epoll的实现原理

深入理解NIO（四）—— epoll的实现原理

本文链接：https://www.cnblogs.com/fatmanhappycode/p/12362423.html

终于来到最后了，万里长征只差最后一步 ( `д´) !

简单流程梳理

我们先从只监听一个socket开始讲起：

首先我们有一个程序A，他运行这下面这样一段代码：

//创建socket
int s = socket(AF_INET, SOCK_STREAM, );
//绑定端口
bind(s, ...)
//监听
listen(s, ...)
//接受客户端连接
int c = accept(s, ...)
//接收客户端数据，没有数据就先阻塞在这里
recv(c, ...);
//将数据打印出来
printf(...)

当程序A运行到recv()的时候它阻塞了，

之后就挂起在等待队列中，等待被唤醒之后继续执行，

而在Linux中，万事万物皆为文件，我们的socket也占用了一个fd。

我们的A就挂在socket中的等待队列中。

接下来我们来看一个简单的流程：

1. 首先第一步是通过网线发送数据到网卡
2. 网卡将数据存到内存中
3. 网卡对cpu发出中断信号，提醒cpu过来处理网卡的任务
4. cpu接到信号后暂时中断自己的任务，过来运行网卡准备的中断程序
5. 中断程序的内容是：将网卡写到内存中的网络数据写入socket的输入缓冲区
6. 然后中断程序再唤醒处于阻塞状态的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, );
bind(s, ...);
listen(s, ...);
int fds[] =  // 存放需要监听的socket;
while(){
    // 这里就是我们的select
    int n = select(..., fds, ...)
    for(int i=; i < fds.count; i++){
        if(FD_ISSET(fds[i], ...)){
            //fds[i]的数据处理
        }
    }
}

这段代码中，先准备了一个数组 fds，让 fds 存放着所有需要监视的 socket。然后调用 select，如果 fds 中的所有 socket 都没有数据，select 会阻塞，直到有一个 socket 接收到数据，select 返回，唤醒进程。用户可以遍历 fds，通过 FD_ISSET 判断具体哪个 socket 收到数据，然后做出处理。

接下来我们看一下流程图：

1. 流程基本都一样，A却存在于多个socket的等待队列中
2. 当某个socket被写入数据时，A也被唤醒并从多个socket的等待队列中移除后加入工作队列
3. 但是此时A并不知道是哪个socket被写入了数据，所以只能遍历所有socket
4. 在A处理完任务后移出工作队列，但是此时却需要遍历所有socket并加入它们的等待队列中

select的缺点在于：

1. 每次调用 select 都需要将进程加入到所有监视 socket 的等待队列，每次唤醒都需要从每个队列中移除。这里涉及了两次遍历，而且每次都要将整个 fds 列表传递给内核，有一定的开销。正是因为遍历操作开销大，出于效率的考量，才会规定 select 的最大监视数量，默认只能监视 1024 个 socket。
2. 进程被唤醒后，程序并不知道哪些 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)

1. 收集在epoll监控的事件中已经发送的事件。
2. 参数events是分配好的epoll_event结构体数组，epoll将会把发生的事件赋值到events数组中（events不可以是空指针，内核只负责把数据复制到这个events数组中，不会去帮助我们在用户态中分配内存）。
3. maxevents告之内核这个events有多大，这个 maxevents的值不能大于创建epoll_create()时的size。
4. 参数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调包师了，你将和我一样找不到工作，おめでとう ！

---

本文参考自 : https://my.oschina.net/editorial-story/blog/3052308#comments，我很喜欢这种讲解风格，不过原博主好像主要写游戏开发类的，可能很难再有我想看的博文了。

Linux epoll API小节搬运自https://www.cnblogs.com/yangang92/p/7469970.html

两种触发模式搬运自https://blog.csdn.net/daaikuaichuan/article/details/83862311?utm_source=distribute.pc_relevant.none-task