深入理解Linux的epoll机制

Linux还有其他方式可以实现IO多路复用吗？

好像没有了！

这3种到底是做啥的？

这3种都能够管理fd的可读可写事件，在所有fd不可读不可写无所事事的时候，可以阻塞线程，切走cpu。fd有情况的时候，都要线程能够要能被唤醒。

而这三种方式以epoll池的效率最高。为什么效率最高？

其实很简单，这里不详说，其实无非就是epoll做的无用功最少，select和poll或多或少都要多余的拷贝，盲猜（遍历才知道）fd，所以效率自然就低了。

举个例子，以select和epoll来对比举例，池子里管理了1024个句柄，loop线程被唤醒的时候，select都是蒙的，都不知道这1024个fd里谁IO准备好了。这种情况怎么办？只能遍历这1024个fd，一个个测试。假如只有一个句柄准备好了，那相当于做了1千多倍的无效功。

epoll则不同，从epoll_wait醒来的时候就能精确的拿到就绪的fd数组，不需要任何测试，拿到的就是要处理的。

下面我们看一下epoll池的使用和原理。

epoll的使用非常简单，只有下面3个系统调用。

就这？是的，就这么简单。

epollcreate负责创建一个池子，一个监控和管理句柄fd的池子；

epollctl负责管理这个池子里的fd增、删、改；

epollwait就是负责打盹的，让出CPU调度，但是只要有“事”，立马会从这里唤醒；

Linux下，epoll一直被吹爆，作为高并发IO实现的秘密武器。其中原理其实非常朴实：epoll的实现几乎没有做任何无效功。我们从使用的角度切入来一步步分析下。

首先，epoll的第一步是创建一个池子。这个使用epoll_create来做：

原型：

示例：

这个池子对我们来说是黑盒，这个黑盒是用来装fd的，我们暂不纠结其中细节。我们拿到了一个epollfd，这个epollfd就能唯一代表这个epoll池。

然后，我们就要往这个epoll池里放fd了，这就要用到epoll_ctl了

原型：

示例：

上面，我们就把句柄11放到这个池子里了，op（EPOLL_CTL_ADD）表明操作是增加、修改、删除，event结构体可以指定监听事件类型，可读、可写。

第一个跟高效相关的问题来了，添加fd进池子也就算了，如果是修改、删除呢？怎么做到时间快？

这里就涉及到你怎么管理fd的数据结构了。

最常见的思路：用list，可以吗？功能上可以，但是性能上拉垮。list的结构来管理元素，时间复杂度都太高O(n)，每次要一次次遍历链表才能找到位置。池子越大，性能会越慢。

那有简单高效的数据结构吗？

有，红黑树。Linux内核对于epoll池的内部实现就是用红黑树的结构体来管理这些注册进程来的句柄fd。红黑树是一种平衡二叉树，时间复杂度为O(logn)，就算这个池子就算不断的增删改，也能保持非常稳定的查找性能。

现在思考第二个高效的秘密：怎么才能保证数据准备好之后，立马感知呢？

epoll_ctl这里会涉及到一点。秘密就是：回调的设置。在epoll_ctl的内部实现中，除了把句柄结构用红黑树管理，另一个核心步骤就是设置poll回调。

思考来了：poll回调是什么？怎么设置？

先说说file_operations->poll是什么？

在fd篇说过，Linux设计成一切皆是文件的架构，这个不是说说而已，而是随处可见。实现一个文件系统的时候，就要实现这个文件调用，这个结构体用structfile_operations来表示。这个结构体有非常多的函数，我精简了一些，如下：

你看到了read，write，open，fsync，poll等等，这些都是对文件的定制处理操作，对于文件的操作其实都是在这个框架内实现逻辑而已，比如ext2如果有对read/write做定制化，那么就会是ext2_read，ext2_write，ext4就会是ext4_read，ext4_write。在open具体“文件”的时候会赋值对应文件系统的file_operations给到file结构体。

那我们很容易知道read是文件系统定制fd读的行为调用，write是文件系统定制fd写的行为调用，file_operations->poll呢？

这个是定制监听事件的机制实现。通过poll机制让上层能直接告诉底层，我这个fd一旦读写就绪了，请底层硬件（比如网卡）回调的时候自动把这个fd相关的结构体放到指定队列中，并且唤醒操作系统。

举个例子：网卡收发包其实走的异步流程，操作系统把数据丢到一个指定地点，网卡不断的从这个指定地点掏数据处理。请求响应通过中断回调来处理，中断一般拆分成两部分：硬中断和软中断。poll函数就是把这个软中断回来的路上再加点料，只要读写事件触发的时候，就会立马通知到上层，采用这种事件通知的形式就能把浪费的时间窗就完全消失了。

划重点：这个poll事件回调机制则是epoll池高效最核心原理。

划重点：epoll池管理的句柄只能是支持了file_operations->poll的文件fd。换句话说，如果一个“文件”所在的文件系统没有实现poll接口，那么就用不了epoll机制。

第二个问题：poll怎么设置？

在epoll_ctl下来的实现中，有一步是调用vfs_poll这个里面就会有个判断，如果fd所在的文件系统的file_operations实现了poll，那么就会直接调用，如果没有，那么就会报告响应的错误码。

你肯定好奇poll调用里面究竟是实现了什么？

总结概括来说：挂了个钩子，设置了唤醒的回调路径。epoll跟底层对接的回调函数是：ep_poll_callback，这个函数其实很简单，做两件事情：

把事件就绪的fd对应的结构体放到一个特定的队列（就绪队列，readylist）；

唤醒epoll，活来啦！

当fd满足可读可写的时候就会经过层层回调，最终调用到这个回调函数，把对应fd的结构体放入就绪队列中，从而把epoll从epoll_wait出唤醒。

这个对应结构体是什么？

结构体叫做epitem，每个注册到epoll池的fd都会对应一个。

就绪队列很高级吗？

就绪队列就简单了，因为没有查找的需求了呀，只要是在就绪队列中的epitem，都是事件就绪的，必须处理的。所以就绪队列就是一个最简单的双指针链表。

小结下：epoll之所以做到了高效，最关键的两点：

内部管理fd使用了高效的红黑树结构管理，做到了增删改之后性能的优化和平衡；

epoll池添加fd的时候，调用file_operations->poll，把这个fd就绪之后的回调路径安排好。通过事件通知的形式，做到最高效的运行；

epoll池核心的两个数据结构：红黑树和就绪列表。红黑树是为了应对用户的增删改需求，就绪列表是fd事件就绪之后放置的特殊地点，epoll池只需要遍历这个就绪链表，就能给用户返回所有已经就绪的fd数组；