--- theme: channing-cyan --- ## 引言 `select/poll、epoll`这些词汇相信诸位都不陌生，因为在`Redis/Nginx/Netty`等一些高性能技术栈的底层原理中，大家应该都见过它们的身影，接下来重点讲解这块内容，不过在此之前，先上一张图概述`Java-NIO`的整体结构： ![Java-NIO体系](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8f6a124ca09646ac913e48163d648d51~tplv-k3u1fbpfcp-watermark.image?) 观察上述结构，其实`Buffer、Channel`的定义并不算复杂，仅是单纯的三层结构，因此对于源码这块不再去剖析，有兴趣的根据给出的目录结构去调试源码，自然也能摸透其原理实现。而最关键的是`Selector`选择器，它是整个`NIO`体系中较为复杂的一块内容，同时它也作为`Java-NIO`与内核多路复用模型的“中间者”，但在上述体系中，却出现了之前未曾提及过的`SelectorProvider`系定义，那么它的作用是干嘛的呢？主要目的是用于创建选择器，在Java中创建一般是通过如下方式： ```java // 创建Selector选择器 Selector selector = Selector.open(); // Selector类 → open()方法 public static Selector open() throws IOException { return SelectorProvider.provider().openSelector(); } ``` 从源码中可明显得知，选择器最终是由`SelectorProvider`去进行实例化，不过值得一提的是：`Selector`的实现是基于工厂模式与`SPI`机制构建的。对于不同`OS`而言，其对应的具体实现并不相同，因此在`Windows`系统下，我们只能观测到`WindowsSelectorXXX`这一系列的实现，而在`Linux`系统时，对于的则是`EPollSelectorXXX`这一系列的实现，所以要牢记的是，**`Java-NIO`在不同操作系统的环境中，提供了不同的实现**，如下： - `Windows`：`select` - `Unix`：`poll` - `Mac`：`kqueue` - `Linux`：`epoll` 当然，本次则重点剖析Linux系统下的`select、poll、epoll`的具体实现，对于其他系统而言，原理大致相同。 ## 一、JDK层面的源码入口简单的对于`Java-NIO`体系有了全面认知后，接下来以`JDK`源码作为入口进行剖析。在Java中，会通过`Selector.select()`方法去监听事件是否被触发，如下： ```java // 轮询监听选择器上注册的通道是否有事件被触发 while (selector.select() > 0){} // Selector抽象类 → select()抽象方法 public abstract int select() throws IOException; // SelectorImpl类 → select()方法 public int select() throws IOException { return this.select(0L); } // SelectorImpl类 → select()完整方法 public int select(long var1) throws IOException { if (var1 < 0L) { throw new IllegalArgumentException("Negative timeout"); } else { return this.lockAndDoSelect(var1 == 0L ? -1L : var1); } } ``` 当调用`Selector.select()`方法后，最终会调用到`SelectorImpl`类的`select(long var1)`方法，而在该方法中，又会调用`lockAndDoSelect()`方法，如下： ```java // SelectorImpl类 → lockAndDoSelect()方法 private int lockAndDoSelect(long var1) throws IOException { // 先获取锁确保线程安全 synchronized(this) { // 在判断当前选择是否处于开启状态 if (!this.isOpen()) { // 如果已关闭则抛出异常 throw new ClosedSelectorException(); } else { // 如若处于开启状态 // 获取所有注册在当前选择器上的事件 Set var4 = this.publicKeys; int var10000; // 再次加锁 synchronized(this.publicKeys) { // 获取所有已就绪的事件 Set var5 = this.publicSelectedKeys; // 再次加锁 synchronized(this.publicSelectedKeys) { // 真正的调用select逻辑，获取已就绪的事件 var10000 = this.doSelect(var1); } } // 返回就绪事件的数量 return var10000; } } } ``` 在该方法中，对于其他逻辑不必太过在意，重点可注意：最终会调用`doSelect()`触发真正的逻辑操作，接下来再看看这个方法： ```java // SelectorImpl类 → doSelect()方法 protected abstract int doSelect(long var1) throws IOException; // WindowsSelectorImpl类 → doSelect()方法 protected int doSelect(long var1) throws IOException { // 先判断一下选择器上是否还有注册的通道 if (this.channelArray == null) { throw new ClosedSelectorException(); } else { // 如果有的话 // 先获取一下阻塞等待的超时时长 this.timeout = var1; // 然后将一些取消的事件从选择器上移除 this.processDeregisterQueue(); // 再判断一下是否存在线程中断唤醒 // 这里主要是结合之前的wakeup()方法唤醒阻塞线程的 if (this.interruptTriggered) { this.resetWakeupSocket(); return 0; } else { // 如果没有唤醒阻塞线程的需求出现 // 先判断一下辅助线程的数量（守护线程），多则减，少则增 this.adjustThreadsCount(); // 更新一下finishLock.threadsToFinish为辅助线程数 this.finishLock.reset(); // 唤醒所有的辅助线程 this.startLock.startThreads(); try { // 设置主线程中断的回调函数 this.begin(); try { // 最终执行真正的poll逻辑，开始拉取事件 this.subSelector.poll(); } catch (IOException var7) { this.finishLock.setException(var7); } // 唤醒并等待所有未执行完的辅助线程完成 if (this.threads.size() > 0) { this.finishLock.waitForHelperThreads(); } } finally { this.end(); } // 检测状态 this.finishLock.checkForException(); this.processDeregisterQueue(); // 获取当前选择器监听的事件的触发数量 int var3 = this.updateSelectedKeys(); // 本轮poll结束，重置WakeupSocket，为下次执行做准备 this.resetWakeupSocket(); // 最终返回获取到的事件数 return var3; } } } ``` 整个过程下来其实也并不短暂，但大体就分为三步： - ①前置动作：判断通道数、获取阻塞时长、移除取消的事件以及判断是否需要被唤醒。 - ②核心动作：更新并唤醒所有辅助线程、设置主线程中断的回调、执行`poll`拉取事件。 - ③后置动作：唤醒辅助线程完成工作、检测状态、重置条件、获取事件数并返回。 > 在这里面，有一个辅助线程的概念，这跟最大文件描述符有关，每当选择器上注册的通道数超过`1023`时，新增一条线程来管理这些新增的通道。其实是`1024`，但其中有一个要用于唤醒，所以是`1023`（这里看可能有些懵，但待会分析过后就理解了）。在这个过程中，最最最关键点在于其中的一行代码： ```java this.subSelector.poll(); ``` 在这里调用了`poll`方法，执行具体的事件拉取逻辑，进一步往下走： ```java // WindowsSelectorImpl类 → poll()方法 private int poll() throws IOException { return this.poll0(WindowsSelectorImpl.this.pollWrapper.pollArrayAddress, Math.min(WindowsSelectorImpl.this.totalChannels, 1024), this.readFds, this.writeFds, this.exceptFds, WindowsSelectorImpl.this.timeout); } // WindowsSelectorImpl类 → poll0()方法 private native int poll0(long var1, int var3, int[] var4, int[] var5, int[] var6, long var7); ``` 最后会调用`WindowsSelectorImpl.poll()`方法，而该方法最终会调用本地的`native`方法：`poll0()`方法，而在`JVM`的源码实现中，该方法最终会调用内核所提供的函数。 > OK~，由于`Windows`有`IDEA`工具辅助，所以方便调试源码，因此这里以`WindowsSelectorXXX`系的举例说明，但由于整个`Java-NIO`的核心组件，都是基于工厂模式编写的源码，所以其他操作系统下的源码位置也相同，仅最终调用的内核函数不同！！！最终稍做总结，`JDK`层面的源码入口，核心流程如下： - ①`Selector`抽象类 → `select()`抽象方法 - ②`SelectorImpl`类 → `select()`方法 - ③`SelectorImpl`类 → `lockAndDoSelect()`方法 - ④`SelectorImpl`类 → `doSelect()`方法 - ⑤`XxxSelectorImpl`类 → `doSelect()`方法 - ⑥`XxxSelectorImpl`类 → `poll()`方法 - ⑦`XxxSelectorImpl`类 → `JNI`本地的`poll0()`方法如若在`Windows`系统下，上述的`XxxSelectorImpl`类则为`WindowsSelectorImpl`，同理，如若在`Linux`系统下，`XxxSelectorImpl`类则为`EpollSelectorImpl`。 > 最后，如果大家对于JDK层面的`EPoll`感兴趣，可自行反编译`Linux`版的`JDK`源码，`EpollSelectorXXX`的相关定义位于：`jdk\src\solaris\classes\sun\nio\ch\`目录下。 ## 二、JDK源码级别的入口经过第一阶段的分析后，会发现最终其实调用了`native`本地方法`poll0()`，在之前的[《JVM运行时数据区-本地方法栈》](https://juejin.cn/post/7057538798686568461#heading-11)的文章提到过，当程序执行时碰到`native`关键字修饰的方法时，会调用`C/C++`所编写的本地方法库中的实现，那么又该如何查找`native`方法对应的源码呢？接着一起来聊一下。 --- ①由于`Oracle-jdk`是收费的，所以咱们首先下载`open-jdk1.8`的源码，可以自行在[Open-JDK官网](http://hg.openjdk.java.net/)下载，但官网下载时，常常会由于网络不稳定而中断，下载起来相当费劲，因此也为大家提供一下[《open-jdk1.8》](https://pan.baidu.com/s/1OpT0I3NxFfcOFKn6OtRSeA?pwd=v5hj)的源码链接。 --- ②下载之后解压源码包，然后进入`jdk8-master\jdk\src\`目录，在其中你会看到不同操作系统下的`Java`实现，`JDK`源码会以操作系统的类型分包，不同系统的对应不同的实现，如下： ![JDK-src](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/29d8c02cb5af4b119fd9dc0ba8437e06~tplv-k3u1fbpfcp-watermark.image?) 但关于`Linux`系统下的`Java-NIO`实现，实际上并不在`linux`目录中，而是在`solaris`目录，进入`solaris`目录如下： ![solaris](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3fd6d5a493f2442094083ba2a4ee6d2e~tplv-k3u1fbpfcp-watermark.image?) `solaris`目录中还包含了`LinuxOS、SunOS(SolarisOS/UnixOS)`以及`MacOS`等操作系统下的`Java-NIO`实现，但关于`MacOS`下的`Java-NIO`完整实现，则位于前面的`macosx`目录中，这里仅包含一部分，结构如下： ![目录结构](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3f21ccbb02b741c28a60f33a68aefd22~tplv-k3u1fbpfcp-watermark.image?) 观察上图会发现，`solaris`目录中包含了`KQueue、EPoll、Poll、DevPoll`等`IO`多路复用模型的`Java`实现，但关于`Mac-KQueue`的完整实现则在`macosx`目录。 > OK~，到目前为止大家对于`JDK`源码的目录结构应该有了基本认知。稍微总结一下，重点就是搞清楚两个位置： - ➊`jdk8-master\jdk\src\xxxOS\classes\sun\nio\ch`：对应`nio`包下的`Java`代码。 - ➋`jdk8-master\jdk\src\xxxOS\native\sun\nio\ch`：对应`nio`包中`native`方法的`JNI`代码。 --- ③搞清楚`JDK`源码目录的结构后，那以之前分析的`Windows-NIO`为例： ```java private native int poll0(long var1, int var3, int[] var4, int[] var5, int[] var6, long var7); ``` 对于`poll0()`这个本地方法，又该如何查找对应的源码呢？根据上述的源码结构，先去到`\windows\native\sun\nio\ch`目录中，然后找到与之对应的`WindowsSelectorImpl.c`文件，最终就能在该文件中定位到对应的`JNI`方法：`Java_sun_nio_ch_WindowsSelectorImpl_00024SubSelector_poll0`（名字略微有些长）。 --- ④找到对应的`JNI`方法源码后，其中存在这么一行： ![win-select](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5b7da8d854e0462fbbab6735c00308ad~tplv-k3u1fbpfcp-watermark.image?) 观察之后不难发现，其实最终还会调用到`OS`内核的提供的`select()`函数，所以`poll0()`实际上会依赖`OS`提供的多路复用函数实现相应的功能，对于其他操作系统而言，也是同理。 > 但是接下来只会重点叙述`Linux`下的三大`IO`多路复用函数：`select、poll、epoll`，而对于`Windows-select、Mac-kqueue`不会进行深入讲解（不是不想分析，而是由于`Windows、Mac`系统都属于闭源的，想分析也无法获取其具体的源码实现过程）。 ## 三、文件描述符与自实现网络服务器到目前可得知：Java中的`NIO`最终会依赖于操作系统所提供的多路复用函数去实现，而`Linux`系统下对应的则是`epoll`模型，但`epoll`的前身则是`select、poll`，因此我们先分析`select、poll`多路复用函数，再分析其缺点，逐步引出`epoll`的由来，最终进一步对其进行全面剖析。相信大家在学习`Linux`时，都听说过“**`Linux`本质上就是一个文件系统**”这句话，在`Linux-OS`中，万事万物皆为文件，连网络连接也不例外，因此在分析多路复用模型之前，咱们首先对这些基础概念做一定了解。 ### 3.1、文件描述符(FD) 在上述中提到过：`Linux`的理念就是“一切皆文件”，在`Linux`中几乎所有资源都是以文件的形式呈现的。如磁盘的数据是文件，网络套接字是文件，系统配置项也是文件等等，所有的数据内容在`Linux`都是通过文件系统来管理的。既然所有的内容都是文件，那当我们要操作这些内容时，又该如何处理呢？为了方便系统执行，`Linux`都是通过文件描述符`File Descriptor`对文件进行操作，对于文件描述符这个概念可以通过一个例子来理解： ```java Object obj = new Object(); ``` 上述是Java创建对象的一行代码，类比`Linux`的文件系统，后面`new Object()`实例化出来的对象可以当成是具体的文件内容，而前面的引用`obj`则可理解为是文件描述符。`Linux`通过`FD`操作文件，其实本质上与`Java`中通过`reference`引用操作对象的过程无异。 > 而当出现网络套接字连接时，所有的网络连接都会以文件描述符的形式在内核中存在，也包括后面会提及的多路复用函数`select、poll、epoll`都会基于`FD`对网络连接进行操作，因此先阐明这点，作为后续分析的基础。 ### 3.2、自己设计网络连接服务器在分析之前，我们先自己设想一下，如果有个需求：请自己设计一套网络连接系统，那么此时你会怎么做呢？此刻例如来了`5`个网络连接，如下： ![socket](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7abfa3f189364064a23833a76c20818d~tplv-k3u1fbpfcp-watermark.image?) 那么又该如何处理这些请求呢？最简单的方式： ![网络服务器](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6b3a42b9aacc4808a51cb7f4790f3ad1~tplv-k3u1fbpfcp-watermark.image?) 对于每个到来的网络连接都为其创建一条线程，每个连接由单独的线程负责处理，所以最初的`BIO`也是这样来的，由于设计起来非常简单，所以它成为了最初的网络`IO`模型，但这种方式的缺陷非常明显，在之前的`BIO`章节也曾分析过，无法支撑高并发的流量访问，因此这种多线程的方式去实现自然行不通了，兜兜转转又得回到单线程的角度去思考，单线程如何处理多个网络请求呢？最简单的方式，伪代码如下： ```java // 不断轮询监听所有的网络连接 while(true){ // 遍历所有的网络套接字连接 for(SocketFD xFD : FDS){ // 判断网络连接中是否有数据 if (xFD.data != null){ // 从套接字中读取网络数据 readData(); // 将网络数据交给应用程序处理（写入对应的程序缓冲区） processingData(); // ...... } } } ``` 如上代码，当有网络连接到来时，将其加入`FDS`数组中，然后由单条线程不断的轮询监听所有网络套接字，如果套接字中有数据，则从中将网络数据读取出来，然后将读取到的网络数据交给应用程序处理。 > 这似乎是不是就通过单线程的方式解决了多个网络连接的问题？答案是`Yes`，但相较而言，性能自然不堪入目，如果内核是这样去处理网络连接，对于并发支持自然也上不去，那`Linux`内核具体是如何处理的呢？一起来看看。 ## 四、多路复用函数 - select() 在`JDK1.8`的源码中，刚刚似乎并未发现`Selectxxx`这系列的定义，这是由于`Linux`内核`2.6`之后的版本中，已经使用`epoll`代替了`select`，所以对应的`JDK1.5`之后版本，也将`Linux-select`的实现给移除了，所以如若想观测到`Linux-select`相关的实现，那还需先安装一个`kernel-2.6`以下的`Linux`系统，以及还需要下载`JDK1.5`的源码，这样才能分析完整的`select`实现。 > 我大致过了一下内核中的源码，对于`select`函数的实现大致在`2000`行左右，大致看下来后，由于对`C`语言没有那么熟悉，并且源码实现较长，因此后续不再以全源码链路的方式剖析，而是适当结合部分核心源码进行阐述。当然，如若你的`C`语言功底还算扎实，那可以下载[《Linux2.6.28.6版本内核源码》](http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.28.6.tar.bz2)解压调试。先讲清楚接下来的分析思路，在后续分析IO多路复用函数时，大体会以调用入口 → 函数定义 → 核心结构体 → 核心源码 → 函数缺陷这个思路进行展开。 ### 4.1、Java-select函数的JNI入口对于`Open-JDK1.4、1.5`的源码，由于年代较久远了，实在没有找到对应的`JDK`源码，所以在这里分析`Linux-select`函数时，就以前面分析的`Windows-select`思路举例说明，如下： - ①`Java`中通过调用选择器的`select()`方法监听客户端连接。 - ②线程执行时，会执行到当前平台对应的选择器实现类的`doSelect()`方法。 - ③接着会调用实现类对应的`poll()`轮询方法，最终在该方法中会调用其`native`方法。 - ④当线程需要执行本地方法时，触发`JNI`调用，会在本地方法库中查找对应的`C`实现。 - ⑤定位到`native`本地方法对应的`C`语言函数，然后执行对应的`C`代码。 - ⑥在`C`代码的函数中，最终会发起系统调用，那假设此时系统调用的函数为`select()`。此时，对于`Java`是如何调用底层操作系统内核函数的过程就分析出来了，但是由于这里没有下载到对应版本的源码，因此无法通过源码进行演示，但就算没有对应的源码作为依据也无大碍，因为无论是什么类型的操作系统，也无论调用的是哪个多路复用函数，本质上入口都是相同的，只是`JNI`调用时会存在些许差异。 ### 4.2、内核select函数的定义 OK~，得知了`Java-NIO`执行的前因后果后，现在来聊一聊最初`NIO`会调用的系统函数：`select`，在`Linux`中的定义如下： ```c // 定义位于/sys/select.h文件中 int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); ``` `select`函数定义中，存在五个参数，如下： - `nfds`：表示`FDS`中有效的`FD`数量，全部文件描述符的最大值`+1`。 - `readfds`：表示需要监控读事件发生的文件描述符集合。 - `writefds`：表示需要监控写事件发生的文件描述符集合。 - `exceptfds`：表示需要监控异常/错误发生的文件描述符集合。 - `timeout`：表示`select`在没有事件触发的情况下，会阻塞的时间。 ### 4.3、select结构体 - fd_set、timeval 在上述中简单了解`select`的定义与参数后，大家可能会有些晕乎乎的，这是由于这五个参数中涉及到两组类型的定义，分别为`fd_set、timeval`，先来看看它们是如何定义的： ```c // 相关定义位于linux/types.h、linux/posix_types.h文件中 // -------linux/types.h---------- // 这里定义了一个__kerenl_fd_set的类型，别名为fd_set。 typedef __kerenl_fd_set fd_set; 省略其他..... // -------linux/posix_types.h---------- /* unsigned long表示无符号长整型，占4bytes/32bits sizeof()函数是求字节的长度，sizeof(unsigned long)=4 因此最终这里的__NFDBITS=(8 * 4)=32 */ #undef __NFDBITS #define __NFDBITS (8 * sizeof(unsigned long)) // 这里限制了最大长度为1024（可修改，不推荐） #undef __FD_SETSIZE #define __FD_SETSIZE 1024 // 根据前面的__NFDBITS求出long数组的最大容量为：1024/32=32个 #undef __FD_SET_LONGS #define __FD_SET_LONGS (__FD_SETSIZE/__NFDBITS) // 这两组定义则是用于置位、复位（清除置位）的 #undef __FDELT #define __FDELT(d) ((d) / __NFDBITS) #undef __FDMASK #define __FDMASK(d) (1UL << (d) % __NFDBITS) // 这里定义了__kerenl_fd_set类型，本质上是一个long数组 typedef struct { unsigned long fds_bits [__FDSET_LONGS]; } __kerenl_fd_set; ``` 观察上述源码，其实你会发现`fd_set`的定义是`__kerenl_fd_set`类型的，而`__kerenl_fd_set`的定义本质上就是一个`long`数组，同时在`__kerenl_fd_set`的定义中，也声明了最大长度为`1024`，相信了解过多路复用函数的小伙伴都知道`select`模型的最大缺陷之一就在于：**最多只能监听`1024`个文件描述符**，而对于具体是为什么，相信看到这个源码大家就彻底清楚了。 > PS：首先基于上述的知识，已经得知最大长度为`1024`，但这`1024`并非代表着：数组可以拥有`1024`个`long`元素，而是限制了这个`long`数组最多只能有`1024`个比特位的长度，也就是数组中最多能拥有`1024/32=32`个元素。对于这点，在源码中也有定义，大家可参考源码中的注释。 OK~，那这个`long`类型的数组究竟有什么作用呢？简单来说明一下，在这个`fd_set`的数组中，其实每个位对应着一个`FD`文件描述符的状态，`0`代表没有事件发生，`1`则代表有事件触发，如下图： ![fd_set](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ea8f363878fc4696924a2e84ce818ceb~tplv-k3u1fbpfcp-watermark.image?) 在这个数组中，所有的`long`元素，在计算机底层本质上都会被转换成`bit`存储，而每一个`bit`位都对应着一个`FD`，所以这个数组本质上就组成了一个位图结构，同时为了方便操作这个位图，在之前的`sys/select.h`文件中还提供了一组宏函数，如下： ```c // 位于/sys/select.h文件中 // 将一个fd_set数组所有位都置零 int FD_ZERO(int fd, fd_set *fdset); // 将指定的某个位复位（赋零） int FD_CLR(int fd, fd_set *fdset); // 将指定的某个位置位（赋一） int FD_SET(int fd, fd_set *fd_set); // 检测指定的某个位是否被置位 int FD_ISSET(int fd, fd_set *fdset); // 这里则是上述宏函数的实现（位操作过程） # define __FD_ZERO(set) \ do { \ unsigned int __i; \ fd_set *__arr = (set); \ for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \ __FDS_BITS (__arr)[__i] = 0; \ } while (0) #define __FD_SET(d, set) \ ((void) (__FDS_BITS (set)[__FD_ELT (d)] |= __FD_MASK (d))) #define __FD_CLR(d, set) \ ((void) (__FDS_BITS (set)[__FD_ELT (d)] &= ~__FD_MASK (d))) #define __FD_ISSET(d, set) \ ((__FDS_BITS (set)[__FD_ELT (d)] & __FD_MASK (d)) != 0) ``` 对于定义的几组宏函数，可以参考上述注释中的解释，而对于这些函数是如何实现的，大家可以自行阅读贴出的源码。接下来再看看`timeval`结构体是如何定义的： ```c struct timeval { long tv_sec; /* 秒 */ long tv_usec; /* 毫秒 */ }; ``` 其实这个结构体就是一个阻塞的时间，好比`select`传入的`timeout`参数为`3`，则`timeval.tv_sec=3、timeval.tv_usec=3000`，代表调用`select()`没有获取到有效事件的情况下，在`3s`内会不断循环检测。当然，这个`timeout`的值会分为三种情况： - `0`：表示调用`select()`函数后不等待，没有就绪事件时直接返回。 - `NULL`：表示调用`select()`函数后无限等待，阻塞至出现中断信号或触发事件后返回。 - 正数：表示调用`select()`函数后，在指定的时间内等待事件触发，超时则返回。 > 至此，对于`select()`函数所需参数中，涉及到的两个结构体已经弄明白了，那么再回来看看`select()`的五个参数。 ```c int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); ``` 调用`select()`时，中间的三个参数要求传入`fd_set`类型，它们分别对应着：那些文件描述符需要监听读事件发生、那些文件描述符需要监听写事件发生、那些文件描述符需要监听异常错误发生。当调用`select()`函数后会陷入阻塞，直到有描述符的事件就绪（有数据可读、可写或出现异常错误）或超时后才会返回。而`select()`函数返回也会存在三种状态： - `0`：当描述符集合中没有事件触发，并且超出设置的时间后，会返回`0`。 - `-1`：当`select`执行过程中，出现异常/错误时则会返回`-1`。 - 正数：如果监视的文件描述符集合中有事件发生（有数据），则会对应的事件数量。 ### 4.4、select()函数的使用案例在上述中已经对于`select()`函数的一些基础知识建立了认知，接下来上个伪代码感受一下`select()`函数的使用过程： ```c /* ----------①---------- */ // 创建服务端socket套接字，并监听客户端连接 serverSockfd = socket(AF_INET,SOCK_STREAM,0); // 省略..... bind(serverSockfd,IP,Port); listen(serverSockfd,numfds); // 这里是已经接收的客户端连接集合 fds[numfds] = accept(serverSockfd,.....); /* ----------②---------- */ // 将所有的客户端连接，分别加入对应的位图中 FD_SET readfds, writefds, exceptfds; int read_count = 0, write_count = 0, except_count = 0; for (i = 0; i < numfds; i++) { if (fds[i].events == 读取事件){ // 加入readfds } if (fds[i].events == 写入事件){ // 加入writefds } // 省略..... } /* ----------③---------- */ // 求出最大的fds值 maxfds = ....; struct timeval timevalue, *tv; // 省略..... /* ----------④---------- */ while(1){ // 初始化位图 FD_ZERO(readfds); FD_ZERO(writefds); FD_ZERO(exceptfds); // 分别对每个位图中需要监听的FD进行置位 for (i = 0; i < numfds; i++) { if (fds[i].events == 读取事件){ FD_SET(fds[i],&readfds); } // 省略其他置位处理..... } // 调用select函数 int result = select(maxfds+1, &readfds, &writefds, &exceptfds, tv); /* ----------⑤---------- */ if (result == 0){ // 处理超时并返回.... } if (result < 0){ // 处理异常并返回.... } /* ----------⑥、⑦---------- */ // 能执行到这里，代表select()返回大于0 for (i = 0; i < numfds; i++) { if(FD_ISSET(fds[i],&readfds)){ // 读取被置位的socket..... read(fds[i], buffer,0,MAXBUF); } // 省略其他...... } } ``` 上述的伪代码虽然看着较多，但本质上并不难，大体分为如下几步： - ①创建服务端的`Socket`套接字并绑定相关的地址，建立监听，等待客户端连接。 - ②将所有的客户端连接，根据注册的事件，分别将其加入到对应的位图中。 - ③求出文件描述符的最大值，并对于超时时间这个参数进行初始化构建。 - ④对位图做置位，调用`select()`函数并传入的相关参数，等待内核处理完成。 - ⑤根据内核的返回结果，进行对应处理，如超时处理、异常处理、事件处理等。 - ⑥如果没有超时以及出现错误，那么则遍历判断那个`FD`有数据的（被置位）。 - ⑦对于有事件发生的`FD`，根据其事件类型进行对应的处理（读、写数据）。对于这个伪代码，其实也是调用`select()`函数的通用模型，以`Java`的`JNI`调用为例，其实大体的过程也是相同的，如下： ![select调用](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f96f2f225de84fad86fa8f8419a85652~tplv-k3u1fbpfcp-watermark.image?) > 没有下载到`JDK1.5`的源码，所以以`Windows-select`的调用为例。 ### 4.5、内核select函数核心源码在上述过程中，我们调用了`select()`函数实现了`IO`多路复用，但调用之后`select()`的执行过程，相对而言其实是未知，那么接着再来看看`select()`的核心源码，剖析一下调用`select`后，内核究竟会如何处理。 > 内核源码的执行流程：`sys_select() → SYSCALL_DEFINE5() → core_sys_select() → do_select() → f_op->poll/tcp_poll()`。所有的系统调用，都可以在它的名字前加上“`sys_`”前缀，这就是它在内核中对应的函数。比如系统调用`open、read、write、select`，与之对应的内核函数为：`sys_open、sys_read、sys_write、sys_select`，因此上述的`sys_select()`其实就是`select()`函数再内核中对应的函数。接着来看看`SYSCALL_DEFINE5()、core_sys_select()`函数的内容： ``` // 位于fs/select.c文件中（sys_select函数） SYSCALL_DEFINE5(select, int, n, fd_set __user *, inp, fd_set __user *, outp, fd_set __user *, exp, struct timeval __user *, tvp) { struct timespec end_time, *to = NULL; struct timeval tv; int ret; // 判断是否传入了超时时间 if (tvp) { if (copy_from_user(&tv, tvp, sizeof(tv))) return -EFAULT; to = &end_time; // 如果已经到了超时时间，则中断执行并返回 if (poll_select_set_timeout(to, tv.tv_sec + (tv.tv_usec / USEC_PER_SEC), (tv.tv_usec % USEC_PER_SEC) * NSEC_PER_USEC)) return -EINVAL; } // 未超时或没有设置超时时间的情况下，调用core_sys_select ret = core_sys_select(n, inp, outp, exp, to); ret = poll_select_copy_remaining(&end_time, tvp, 1, ret); return ret; } // 位于fs/select.c文件中（core_sys_select函数） int core_sys_select(int n, fd_set __user *inp, fd_set __user *outp, fd_set __user *exp, struct timespec *end_time) { fd_set_bits fds; void *bits; int ret, max_fds; unsigned int size; struct fdtable *fdt; /* 由于涉及到了用户态和内核态的切换，因此将位图存储在栈上，（尽量提升状态切换时的效率，这里采用栈的方式存储） */ long stack_fds[SELECT_STACK_ALLOC/sizeof(long)]; ret = -EINVAL; if (n < 0) goto out_nofds; // 先计算出max_fds值 rcu_read_lock(); fdt = files_fdtable(current->files); max_fds = fdt->max_fds; rcu_read_unlock(); if (n > max_fds) n = max_fds; // 根据前面计算的max_fds值，判断一下前面开栈空间是否足够 // （在这里涉及到一个新的结构体：fd_set_bits，稍后详细分析） size = FDS_BYTES(n); bits = stack_fds; if (size > sizeof(stack_fds) / 6) { // 如果空间不够则调用内核的kmalloc为fd_set_bits分配更大的空间 ret = -ENOMEM; bits = kmalloc(6 * size, GFP_KERNEL); if (!bits) goto out_nofds; } // 将fd_set_bits中六个位图指针指向分配好的内存位置 fds.in = bits; fds.out = bits + size; fds.ex = bits + 2*size; fds.res_in = bits + 3*size; fds.res_out = bits + 4*size; fds.res_ex = bits + 5*size; // 将用户空间提交的三个fd_set拷贝到内核空间 if ((ret = get_fd_set(n, inp, fds.in)) || (ret = get_fd_set(n, outp, fds.out)) || (ret = get_fd_set(n, exp, fds.ex))) goto out; zero_fd_set(n, fds.res_in); zero_fd_set(n, fds.res_out); zero_fd_set(n, fds.res_ex); // 调用select模型的核心函数do_select() ret = do_select(n, &fds, end_time); if (ret < 0) goto out; // 检测到有信号则系统调用退出，返回用户空间执行信号处理函数 if (!ret) { ret = -ERESTARTNOHAND; if (signal_pending(current)) goto out; ret = 0; } if (set_fd_set(n, inp, fds.res_in) || set_fd_set(n, outp, fds.res_out) || set_fd_set(n, exp, fds.res_ex)) ret = -EFAULT; // goto跳转的对应点 out: if (bits != stack_fds) kfree(bits); out_nofds: return ret; } ``` 源码看过去，看起来有些多，对于`C`语言不太熟悉的小伙伴可能看的会一脸懵，但没关系，我们不去讲细了，重点理解其主干内容，上述源码分为如下几步： - ①先判断调用`select()`时，是否设置了超时时间： - 是：记录一下超时的时间点，并判断一下是否超时，超时则中断并返回。 - 否：没有超时或没设置超时时间，则调用`core_sys_select()`函数。 - ②计算出最大的文件描述符，然后采用开栈方式存储递交的参数值。 - ③根据计算出的`max_fds`值，判断开栈空间能否可以存储递交的参数值： - 不能：调用内核的`kmalloc`分配器为`fd_set_bits`分配更大的空间（新分配的内存是在堆）。 - 能：更改`fd_set_bits`中的指针指向，然后将递交的三个`fd_set`拷贝到内核空间。 - ④上述工作全部已就绪后，调用`select()`函数中的核心函数：`do_select()`处理。在上述过程中，理解起来并不复杂，唯一的疑惑点就在于多出了一个新的结构体：`fd_set_bits`，那它究竟是什么意思呢？先来看看它的定义： ```c typedef struct { unsigned long *in, *out, *ex; unsigned long *res_in, *res_out, *res_ex; } fd_set_bits; ``` 很明显，`fd_set_bits`是由六个元素组成的，这六个元素分别对应着六个位图，其中前三个则对应调用`select()`函数时递交的三个参数：`readfds、writefds、exceptfds`，而后三个则对应着`select()`执行完成之后返回的位图，为什么还需要有后面三个呢？ > 因为`select()`在遍历需要监听的文件描述符列表时，也需要三个对应的位图来记录哪些`FD`中是有数据的，因此也需要有三个位图对应着传入的三个位图，在`select()`执行完成后，如若有`Socket`中存在数据需要处理，那则会将这三个位图中对应的`Socket`位置进行置位，然后从内核空间再将其拷贝回用户空间，以供程序处理。 OK~，了解`fd_set_bits`结构后，对于`core_sys_select`函数中做的工作就自然理解了，一句话总结一下这个函数做的工作： > `core_sys_select`只不过是在为后面要调用的`do_select()`函数做准备工作而已。当然，在上述的`core_sys_select`函数中还涉及到两个函数：`get_fd_set()、set_fd_set()`，其实现如下： ```c // 调用了copy_from_user()函数，也就是从用户空间拷贝数据到内核空间 static inline int get_fd_set(unsigned long nr, void __user *ufdset, unsigned long *fdset) { nr = FDS_BYTES(nr); if (ufdset) return copy_from_user(fdset, ufdset, nr) ? -EFAULT : 0; memset(fdset, 0, nr); return 0; } // 调用了__copy_to_user()函数，也就是将数据从内核空间拷贝回用户空间 static inline unsigned long __must_check set_fd_set(unsigned long nr, void __user *ufdset, unsigned long *fdset) { if (ufdset) return __copy_to_user(ufdset, fdset, FDS_BYTES(nr)); return 0; } ``` 从最终调用的`copy_from_user()、copy_to_user()`两个函数中就能得知，这就是用于用户空间与内核空间之间数据拷贝的函数而已。那么再来看看`select()`的核心函数`do_select()`吧，先上源码： ```c int do_select(int n, fd_set_bits *fds, struct timespec *end_time) { ktime_t expire, *to = NULL; // -------- 核心结构：poll_wqueues ------------- struct poll_wqueues table; poll_table *wait; int retval, i, timed_out = 0; unsigned long slack = 0; // 先获取一下最大的文件描述符 rcu_read_lock(); retval = max_select_fd(n, fds); rcu_read_unlock(); // 如果获取到的值为负数，则返回select()执行过程中错误 if (retval < 0) return retval; n = retval; // 初始化poll_wqueues结构体中的poll_table，并更改__pollwait的指针指向 poll_initwait(&table); wait = &table.pt; // 如果系统调用select()函数时，设置的超时时间为0， // 那么赋值timed_out = 1，表示未获取到事件的情况下不阻塞，直接返回。 if (end_time && !end_time->tv_sec && !end_time->tv_nsec) { wait = NULL; timed_out = 1; } // 如果设置了超时时间，则预估一下还剩下多少时间 if (end_time && !timed_out) slack = estimate_accuracy(end_time); retval = 0; // 这个是最终返回的值 // 开启轮询，这里是核心！！！ for (;;) { unsigned long *rinp, *routp, *rexp, *inp, *outp, *exp; // 对于每个需要监听的fd，向其等待队列中注册后一个entry set_current_state(TASK_INTERRUPTIBLE); // 准备工作 inp = fds->in; outp = fds->out; exp = fds->ex; rinp = fds->res_in; routp = fds->res_out; rexp = fds->res_ex; for (i = 0; i < n; ++rinp, ++routp, ++rexp) { unsigned long in, out, ex, all_bits, bit = 1, mask, j; unsigned long res_in = 0, res_out = 0, res_ex = 0; const struct file_operations *f_op = NULL; struct file *file = NULL; // 做一次位或操作，对于并集为0的FD直接忽略 // （在前面分析过，只有置位=1的，才代表这个FD需要被监听事件） in = *inp++; out = *outp++; ex = *exp++; all_bits = in | out | ex; if (all_bits == 0) { i += __NFDBITS; continue; } // 内层循环：开始对需要监听的FD进行扫描（核心中的核心！！） for (j = 0; j < __NFDBITS; ++j, ++i, bit <<= 1) { int fput_needed; if (i >= n) break; if (!(bit & all_bits)) continue; file = fget_light(i, &fput_needed); // 这里是重点：主要做了f_op->poll这个操作（具体含义后面细聊） if (file) { f_op = file->f_op; mask = DEFAULT_POLLMASK; // 检测对应的FD是否能够进行IO操作 if (f_op && f_op->poll) // 会调用具体设备的poll()方法 mask = (*f_op->poll)(file, retval ? NULL : wait); fput_light(file, fput_needed); // 判断对应的文件描述符目前的状态 // 如果是可读状态，则将其res_in集合对应的坑位置1 if ((mask & POLLIN_SET) && (in & bit)) { res_in |= bit; retval++; } // 如果是可写状态，则将其res_out集合....... if ((mask & POLLOUT_SET) && (out & bit)) { res_out |= bit; retval++; } if ((mask & POLLEX_SET) && (ex & bit)) { res_ex |= bit; retval++; } } } // 对于监听到有数据的FD，赋值给之前要返回的位图中 if (res_in) *rinp = res_in; if (res_out) *routp = res_out; if (res_ex) *rexp = res_ex; cond_resched(); } // 如果扫描到了活跃FD、或出现超时、出现唤醒信号以及指向碰到错误 // 中断循环扫描，返回到之前的core_sys_select()函数中 // 如若是被唤醒或超时了，则会重新扫描一次所有FD wait = NULL; if (retval || timed_out || signal_pending(current)) break; if (table.error) { retval = table.error; break; } // 第一次循环时，如果设置了超时时间，那么则将时间赋值给to指针 if (end_time && !to) { expire = timespec_to_ktime(*end_time); to = &expire; } /* 未扫描到活跃的FD，则调用schedule_hrtimeout_range函数，函数作用：让当前程序进入睡眠，让出CPU资源，避免无效扫描浪费CPU，调用时传入了to，这是调用时指定的阻塞时间，超时则返回0，如果在睡眠过程中，被socket唤醒则返回-EINTR */ if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS)) timed_out = 1; // 睡眠超时后置1，方便后面退出循环返回到上层 } __set_current_state(TASK_RUNNING); // 清理各个驱动程序的等待队列头， // 同时释放所有空出来的poll_table_page页(包含的poll_table_entry) poll_freewait(&table); // 返回扫描到的活跃FD数量 return retval; } ``` 对于源码的执行过程，在上面都已给出了相关注释，但看起来有些费力，我们稍后再去总结一遍，但在此之前我们需要先理解两个内容：活跃`FD`数、`poll_wqueues`结构体。 > 活跃`FD`数：表示有事件发生的文件描述符，比如一个网络套接字中有数据可读，那么这个`Socket`对应的`FD`则可记为一次活跃数。如果一个`FD`同时触发了两个事件，那么则会计算两次活跃数。 `poll_wqueues`结构体则属于`do_select()`函数中的一个核心结构，定义如下： ```c // 位于include/linux/poll.h文件中 struct poll_wqueues { // 驱动注册，回调函数__pollwait的指针 poll_table pt; // 如果下面的inline_entries不够就会需要 struct poll_table_page * table; int error; // 记录下面的table使用过的下标 int inline_index; // 对应下述的poll_table_entry结构 struct poll_table_entry inline_entries[N_INLINE_POLL_ENTRIES]; }; // 加入等待队列的节点 struct poll_table_entry { struct file * filp; wait_queue_t wait; wait_queue_head_t * wait_address; }; // 回调函数的指针 typedef struct poll_table_struct { poll_queue_proc qproc; } poll_table; ``` 对于这个结构体而言，核心就在于其中的`pt`成员，它是`poll_table`类型的，不过想要理解它，那首先必须明白一个知识点： > 当某个进程需要对一个`IO`设备（例如`socket`）进行读写时，如果发现此设备的数据暂且还未就绪，所以不能进行读写操作，当前进程就需要阻塞等待。为了实现阻塞进程，那每个`socket`/`IO`设备都有个等待队列，当进程需要阻塞等待数据时，就可以将该进程添加到对应的等待队列中进行休眠，当`socket`数据就绪后，再唤醒队列中的进程。而`poll_table`结构就是为了将进程添加到等待队列中而创造的，在上述源码中调用`poll_initwait()`函数后，就会将`poll_wqueues`中的`poll_table`成员的`poll_queue.proc`设置为`__pollwait()`回调函数，当后续执行到`f_op->poll()`时会调用`poll_wait()`函数，最终就会执行到这里设置的`__pollwait()`回调，这两个函数实现如下： ``` // 将当前进程添加到wait参数指定的等待列表(poll_table)中 poll_wait(struct file *filp, wait_queue_head_t *queue, poll_table *wait) { if (p && wait_address) p->qproc(filp, wait_address, p); } // 设置唤醒回调函数为pollwake函数，并将poll_table_entry.wait加入等待队列 static void __pollwait(struct file *filp, wait_queue_head_t *wait_address, poll_table *p) { struct poll_wqueues *pwq = container_of(p, struct poll_wqueues, pt); struct poll_table_entry *entry = poll_get_entry(p); if (!entry) return; get_file(filp); entry->filp = filp; // 设置等待队列头 entry->wait_address = wait_address; // 设置关注的事件 entry->key = p->key; // 设置等待队列节点的回调函数为pollwake() init_waitqueue_func_entry(&entry->wait, pollwake); // 私有数据 poll_wqueues entry->wait.private = pwq; // 将 poll_table_entry 添加到对应的等待队列上 add_wait_queue(wait_address, &entry->wait); } ``` OK~，到这里看的可能会有些懵，因为这是跟后续的唤醒动作有关的，待会儿结合具体的设备驱动一起来理解，现在咱们重点先分析一下`do_select()`函数的核心过程： - ①准备阶段：获取最大文件描述符值、设置阻塞回调、处理超时时间等。 - ②开启轮询，将不需要监听的`FD`忽略，需要监听的`FD`都向其等待队列注册一个`entry`。 - ③开启循环将所有需要监听的`FD`全部扫描一遍，判断`FD`对应的设备是否有数据可读写： - 有：直接跳到步骤⑤。 - 没有：内核调用`schedule`让当前进程睡眠`xx`秒，让出`cpu`进入阻塞。 - ④如果有`FD`主动唤醒了当前进程，或`xx`秒后自己醒了，再次跳回步骤③。 - ⑤如果从文件描述符集合中扫描到了有数据可读写的`FD`，记录相应的活跃个数。 - ⑥将就绪事件结果保存在`fds`的`res_in、res_out、res_ex`集合中，然后调用`poll_freewait()`函数移除各个驱动程序的等待队列头，最后返回对应的活跃`FD`数。 `do_select()`函数的核心流程总结给出来了，其实粗略理解起来也不难，唯一有些绕的估计就是进程阻塞/唤醒这块的内容，下面重点来说一下这块。 > 在`do_select()`中，扫描`FD`时有一个核心操作： > `mask = (*f_op->poll)(file, retval ? NULL : wait);` > 在这步操作中，会调用文件描述符对应设备的`poll`检测当前是否能够进行`IO`操作，那么对于网络`Socket`套接字而言，调用`poll`之后，对应的接口就是`sock_poll()`，其定义位于`net/ipv4/`，如下： ```c static unsigned int sock_poll(struct file *file, poll_table * wait) { struct socket *sock; sock = socki_lookup(file->f_dentry->d_inode); return sock->ops->poll(file, sock, wait); } ``` 实现很简单，首先会通过`socki_lookup()`函数将文件描述符转换为具体的`Socket`套接字，然后会调用该`socket.poll()`函数，例如这里的套接字是`TCP`类型的，那么对应的实现就是`tcp_poll()`函数： ```c // 位于net/ipv4/tcp/目录下 unsigned int tcp_poll(struct file *file, struct socket *sock, poll_table *wait) { unsigned int mask; struct sock *sk = sock->sk; struct tcp_sock *tp = tcp_sk(sk); poll_wait(file, sk->sk_sleep, wait); if (sk->sk_state == TCP_LISTEN) return inet_csk_listen_poll(sk); // 用mask来记录socket数据是否可被读写 mask = 0; // 开始进行判断 if (sk->sk_err) mask = POLLERR; if (sk->sk_shutdown == SHUTDOWN_MASK || sk->sk_state == TCP_CLOSE) mask |= POLLHUP; if (sk->sk_shutdown & RCV_SHUTDOWN) mask |= POLLIN | POLLRDNORM | POLLRDHUP; if ((1 << sk->sk_state) & ~(TCPF_SYN_SENT | TCPF_SYN_RECV)) { int target = sock_rcvlowat(sk, 0, INT_MAX); if (tp->urg_seq == tp->copied_seq && !sock_flag(sk, SOCK_URGINLINE) && tp->urg_data) target--; if (tp->rcv_nxt - tp->copied_seq >= target) mask |= POLLIN | POLLRDNORM; if (!(sk->sk_shutdown & SEND_SHUTDOWN)) { if (sk_stream_wspace(sk) >= sk_stream_min_wspace(sk)) { mask |= POLLOUT | POLLWRNORM; } else { /* send SIGIO later */ set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags); set_bit(SOCK_NOSPACE, &sk->sk_socket->flags); /* Race breaker. If space is freed after * wspace test but before the flags are set, * IO signal will be lost. */ if (sk_stream_wspace(sk) >= sk_stream_min_wspace(sk)) mask |= POLLOUT | POLLWRNORM; } } if (tp->urg_data & TCP_URG_VALID) mask |= POLLPRI; } // 最终返回当前socket是否可被读写 return mask; } ``` 在这个函数中，首先会调用`poll_wait()`函数将当前进程添加到`wait`等待列表中，然后检测`socket`目前数据是否可以被读写，最终通过`mask`变量来记录当前套接字的数据是否可被读写，如果可读写会将对应的`FD`记录为活跃状态。如若不可读写则会先返回，然后等当前进程遍历完所有`FD`后，所有的`FD`都不能进行`I/O`操作的情况下，当前进程则会进入休眠阻塞状态。 > 如果进程陷入休眠阻塞状态后，它被再次唤醒只有两种情况： > ①为进程设置的休眠时间到了自己醒来。 > ②由对应的驱动设备主动唤醒。第一种情况都懂就不聊了，重点来说说第二种，这种唤醒则是由`I/O`设备决定的，之前分析`__pollwait`函数时，在最后调用了`add_wait_queue(wait_address, &entry->wait)`函数，在对应的等待队列上插入了一个`entry`，那当`I/O`设备的数据就绪后，就会去遍历等待队列找到这个`entry`，然后会调用设置好的`pollwake()`回调函数唤醒对应的进程。此时由于数据已经准备好了，所以当`select`被唤醒后，自然就能扫描到对应的`FD`变为了可读写状态，然后返回给用户态的程序。 > 当然，对于唤醒这块的具体实现位于`/sys/wait.h、wait.c`文件中，感兴趣的可自行研究。至此，`select()`函数被调用后，在内核具体是如何工作的，整个源码流程也就大致分析清楚了，现在咱们会简单总结一下，梳理清楚完整流程。 ### 4.6、select底层原理小结在经过上述一系列分析后，我们大致摸透了`select()`运行的底层原理，但估摸着大家看下来都有一点云里雾里的感觉，因此再简单的写一个完整流程的总结： - ①外部调用`select()`函数，传入最大文件描述符值、三个`FD`集合以及超时时间。 - ②用六个位图组成的`fd_set_bits`结构存储传入的`FD`集合，用`kmalloc`为其分配栈空间。 - ③将用户态传递的`fd_set`拷贝到内核空间，紧接着调用`do_select()`函数。 - ④获取传入的最大文件描述符值、设置阻塞回调函数、处理超时时间等。 - ⑤开启轮询，将不需要监听的`FD`忽略，需要监听的`FD`都向其等待队列注册一个`entry`。 - ⑥开启循环将所有需要监听的`FD`全部扫描一遍，判断`FD`对应的设备是否有数据可读写： - 有：直接跳到步骤⑧。 - 没有：内核调用`schedule`让当前进程睡眠`xx`秒，让出`cpu`进入阻塞。 - ⑦如果有`FD`主动唤醒了当前进程，或`xx`秒后自己醒了，再次跳回步骤⑥。 - ⑧如果从文件描述符集合中扫描到了有数据可读写的`FD`，记录相应的活跃个数。 - ⑨将就绪事件结果保存在`fds`的`res_in、res_out、res_ex`集合中，然后调用`poll_freewait()`函数移除各个驱动程序的等待队列头，最后返回对应的活跃`FD`数。 - ⑩将扫描到的`FD`从内核拷贝会用户态空间，同时向程序返回已触发的事件数。其实整个流程下来，`select`分析的内容颇多，这是因为它也是后续两个函数的基础，把它的过程弄明白了，在分析后面的函数时，过程也是换汤不换药的，步骤都大致相同。 ### 4.7、select的缺点分析与思考详细了解了`select()`函数后，再来想想它有哪些不足的地方呢？ > ①由`32`个`long`元素组成的`fd_set`，最大只能表示`1024`位，因此最多只能监听`1024`个`socket`，所以对于高并发的`I/O`场景很难提供支持。 > ②因为监听`FD`的工作是内核完成的，所以每次调用`select()`时，都需将`FD`集合从用户态拷贝到内核态空间，这个过程开销会较大。 > ③当监听的`FD`集合中，某个`Socket`上有数据可读写后，会唤醒陷入睡眠的`select`，但`select`醒来后也不知道那个`FD`有数据，因此会重新将整个集合遍历一次，造成了很大程度上的浪费。 > ④每次调用`select`函数时，由于需要监听的文件描述符不同，所以需要构建新的`fd_set`集合，也就是上一次使用过的`fd_set`不可被重用，造成较大的资源开销。上述四点，则是`select`多路复用模型的四个致命缺陷，由于这些原因导致它并不适合于一些高性能的场景，因此才有后续的`poll、epoll`等模型出现。但在分析其他两个函数之前，再思考一个问题，假设此时`CPU`正在处理一个`IO`数据，但此刻另外一个`Socket`上也来了数据，那么这个数据会被丢弃吗？ > 答案是不会的，因为有专门用于处理`I/O`数据的硬件：`DMA`控制器以及网卡，在网络连接到来时，如果`CPU`正在处理另外一条网络连接的数据，新连接的网络数据并不会被丢弃，而是会由网卡将数据接收并放入内核缓冲区。同理，如果是本地`IO`，则会由`DMA`控制器处理。 ## 五、多路复用函数 - poll() `poll`函数则是基于`select`函数创造出来的，其实它和`select`的区别不大，唯一一点区别就在于：核心结构不同了，在`poll`中出现了一种新的结构体`pollfd`，它不存在最大数量的限制。但其实`poll`的性能与`select`差距是不大的，因此可以将`poll`理解成增强版`select`。 ### 5.1、poll()函数的定义 `poll`的定义也和`select`相差不大，准确来说，所有的多路复用函数定义都差不多，如下： ```c int poll(struct pollfd* fds, nfds_t nfds, int timeout); ``` 相较之前的`select`函数，`poll`的入参少了两个，这是因为在其中将结构体优化成了`pollfd`，关于这点待会儿聊。先看看三个入参： - `fds`：这是由`pollfd`组成的数组，数组每个元素表示要监听的文件描述符及相应的事件。 - `nfds`：这里表示数组中一共传了多少个元素。 - `timeout`：这个参数很好理解，表示未获取到就绪事件时，允许的等待时间。然后再看看这个函数的返回，也是一个`int`值，和`select`函数的返回值含义相同，也包括后续会分析的`epoll`，返回值也是`int`类型，其含义也都一样。 ### 5.2、poll()的核心结构体：pollfd 紧接着再来看看`poll`的结构体：`pollfd`，其定义如下： ```c struct pollfd{ int fd; short events; short revents; }; ``` 这个结构体中有三个成员，分别对应着：文件描述符、需要监听的事件以及触发的事件，其中`fd、events`是在调用时就需传入的，而`revents`则是由内核监听到事件触发后填充的。 ### 5.3、poll()底层源码分析了解了`pollfd`结构之后，对于`poll()`的使用方式和`select`大致相同，所以不再举例说明，接下来再看看`poll()`的源码过程，其实过程也大致与`select`相似，并且其实现也同样位于`select.c`文件中，执行流程如下： > `sys_poll → SYSCALL_DEFINE3 → do_sys_poll → do_poll → f_op->poll` 整个过程中，最核心的就是`do_poll()`函数，但先来看看前面的函数实现： ```c // 位于fs/select.c文件中（sys_select函数） SYSCALL_DEFINE3(poll, struct pollfd __user *, ufds, unsigend int, nfds, long, timeout_msesc) { struct timespec end_time, *to = NULL; int ret; // 判断是否传入了超时时间，如果传入了则进行相应的超时处理 if (timeout_msesc > 0) { to = &end_time; poll_select_timeout(to, timeout_msesc / MSEC_PER_SEC, NSEC_PER_MSEC * (timeout_msecs % MSEC_PER_SEC)); } // 调用最为核心的 do_sys_poll()函数 ret = do_sys_poll(n, inp, outp, exp, to); if (ret == -EINTR) { struct restart_block *restart_block; restart_block = ¤t_thread_info()->restart_block; restart_block->fn = do_restart_poll; restart_block->poll.ufds = ufds; restart_block->poll.nfds = nfds; if (timeout_msesc >= 0) { restart_block->poll.tv_sec = end_time.tv_sec; restart_block->poll.tv_nsec = end_time.tv_nsec; restart_block->poll.has_timeout = 1; } else restart_block->poll.has_timeout = 0; ret = -ERESTART_REESTARTBLOCK; } return ret; } ``` 这个函数仅是过渡的作用，稍微做了一些辅助工作，然后就直接调用了`do_sys_poll`，那么再来看看这个，源码实现如下： ```c int do_sys_poll(struct pollfd __user *ufds, unsigned int nfds, struct timespec *end_time) { // 这里依旧用到了poll_wqueues结构 struct poll_wqueues table; int err = -EFAULT, fdcount, len, size; // 这里和select相同，采用栈方式存储用户态传递的数据 // 同时在这里是基于long做了对齐填充的，能够充分利用局部性原理 long stack_pps[POLL_STACK_ALLOC/sizeof(long)]; // poll_list是新的结构体：本质上是一个单向链表 struct poll_list *const head = (struct poll_list *)stack_pps; struct poll_list *walk = head; // 定义链表头结点 unsigned long todo = nfds; if (nfds > current->signal->rlim[RLIMIT_NOFILE].rlim_cur) return -EINVAL; len = min_t(unsigned int, nfds, N_STACK_PPS); // 将用户空间传入的所有FD，以链表的形式填充在poll_list中 for (;;) { walk->next = NULL; walk->len = len; if (!len) break; // 将用户态传递的数据拷贝到内核空间 if (copy_from_user(walk->entries, ufds + nfds-todo, sizeof(struct pollfd) * walk->len)) goto out_fds; todo -= walk->len; if (!todo) break; // 在这里如若空间不够，也会调用kmalloc分配更大的空间 len = min(todo, POLLFD_PER_PAGE); size = sizeof(struct poll_list) + sizeof(struct pollfd) * len; walk = walk->next = kmalloc(size, GFP_KERNEL); if (!walk) { err = -ENOMEM; goto out_fds; } } // 这里依旧调用了poll_initwait函数做了初始化工作 poll_initwait(&table); // 然后这里是重点：调用了do_poll()函数对FD做监听 fdcount = do_poll(nfds, head, &table, end_time); // 善后工作：清空各设备等待队列上的节点信息 poll_freewait(&table); for (walk = head; walk; walk = walk->next) { struct pollfd *fds = walk->entries; int j; // 这是最后的工作：将监听到的事件填充到revents中， // 然后通过__put_user写回用户态空间，最后利用goto跳转返回 for (j = 0; j < walk->len; j++, ufds++) if (__put_user(fds[j].revents, &ufds->revents)) goto out_fds; } err = fdcount; out_fds: walk = head->next; while (walk) { struct poll_list *pos = walk; walk = walk->next; kfree(pos); } return err; } ``` 在这里面，其实就是将之前的`do_select()`函数的工作拆开了，拆为了`do_sys_poll、do_poll`两个函数实现，其他过程大致与`do_select`函数相同，不同点在于这里面又出现了一个新的结构体：`poll_list`，定义如下： ```c struct poll_list { struct poll_list *next; int len; struct pollfd entries[0]; }; ``` 从上述结构体的成员很明显就可看出，这是一个典型的单向的数组链表结构，第一个成员代表下一个节点（数组链表）是谁，第二个成员代表后面可变长数组的元素数量，第三个成员则是一个变长数组，里面存放当前这段内存上的`pollfd`。 > 对于这个变长数组大家会存在些许疑惑，明明上面定义的长度为`[0]`，为何可以变长呢？这是利用到了`C`语言里的数组拓展技术，感兴趣的可点击[>>这里<<](https://blog.csdn.net/zxm342698145/article/details/82562235)详细了解。同时，对于“数组链表结构”大家可能有些许疑惑，链表、数组这是两个结构，为何会被组合在一块呢？这是由于`poll`中，会先采用栈上分配的方式存储`pollfd`，但是当用户态传入的`pollfd`过多时，栈上内存可能不太够用，因此就会调用`kmalloc`分配新的内存，而前面分析`select`时提过：**`kmalloc`分配的新空间是基于堆内存的**，所以此时`poll`就会同时使用多块内存，示意图如下： ![poll_list](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/988f332f937649209dd1bd40e6b452ba~tplv-k3u1fbpfcp-watermark.image?) > 也就是说：如果栈上能存储用户空间传递的`pollfd`，那么只会出现一个`poll_list`在栈上，如果存储不下则会有多个，除开第一个数组外，其他的都在堆上，因此`poll_list`结构中的指针会指向另外一个数组。 OK~，弄明白了`poll_list`结构体后，对于`do_sys_poll`函数的执行流程就不再重复了，大家可参考我源码中给出的备注，下面直入主题，一起来看看`do_poll()`函数会做什么工作： ```c static int do_poll(unsigned int nfds, struct poll_list *list, struct poll_wqueues *wait, struct timespec *end_time) { // 在这里会注册等待阻塞时的回调函数 poll_table* pt = &wait->pt; ktime_t expire, *to = NULL; int timed_out = 0, count = 0; unsigned long slack = 0; // 处理超时时间 if (end_time && !end_time->tv_sec && !end_time->tv_nsec) { pt = NULL; timed_out = 1; } if (end_time && !timed_out) slack = estimate_accuracy(end_time); // 开启轮询：一直监听所有的pollfd for (;;) { struct poll_list *walk; set_current_state(TASK_INTERRUPTIBLE); // 外层循环：遍历所有的poll_list for (walk = list; walk != NULL; walk = walk->next) { struct pollfd * pfd, * pfd_end; pfd = walk->entries; pfd_end = pfd + walk->len; // 内存循环：遍历poll_list.entries数组中的所有pollfd for (; pfd != pfd_end; pfd++) { // 对于每个pollfd对应的驱动的poll() if (do_pollfd(pfd, pt)) { // 返回值不为0，表示当前FD有数据可读写，count++ count++; pt = NULL; } } } // 这里是防止下次循环时再次注册等待队列 pt = NULL; if (!count) { count = wait->error; if (signal_pending(current)) count = -EINTR; } if (count || timed_out) break; // 在第一次循环时，如果设置了超时时间，那么做一次转换 if (end_time && !to) { expire = timespec_to_ktime(*end_time); to = &expire; } // 如若没有FD出现读写事件，则让当前进程陷入睡眠阻塞状态 if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS)) timed_out = 1; } __set_current_state(TASK_RUNNING); // 最终返回扫描出的活跃FD数量 return count; } ``` 其实在这个过程中，无非就是开启轮询对之前的`poll_list`进行遍历，然后会对每个`pollfd`调用`do_pollfd`函数，就是检测每个`FD`上数据是否可读写，如果所有`pollfd`都遍历完成后，依旧没有发现可读写的`FD`，则让当前进程睡眠阻塞，由于在函数最开始也设置了回调函数，因此当某个`FD`数据准备就绪后，会由对应的驱动程序唤醒`poll`。最后再把`do_pollfd`函数的实现放出来： ```c static inline unsigned int do_pollfd(struct pollfd *pollfd, poll_table *pwait) { // 定义了一个mask接收FD的可读写状态 unsigned int mask; int fd; mask = 0; fd = pollfd->fd; if (fd >= 0) { int fput_needed; struct file * file; file = fget_light(fd, &fput_needed); mask = POLLNVAL; if (file != NULL) { mask = DEFAULT_POLLMASK; // 在这里又再次对每个FD的poll进行了调用 if (file->f_op && file->f_op->poll) // 这行代码与之前select函数的相同 mask = file->f_op->poll(file, pwait); /* Mask out unneeded events. */ mask &= pollfd->events | POLLERR | POLLHUP; fput_light(file, fput_needed); } } pollfd->revents = mask; return mask; } ``` 这个函数的工作不出所料，的确就是对每个`FD`进行了询问：“你的数据可不可以让我进行读写操作呀”？剩下的工作与`select`函数后面的过程相同，因此不再继续分析，想要加深印象的再跳回`select`最后那段分析即可。 ### 5.4、poll()总结与劣势浅谈到目前为止，关于多路复用模型中的`poll()`函数也分析明白了，其实有了`select`函数的基础后，对于`poll`而言，看起来相信应该是十分轻松的。当然，由于`poll()`函数的实现和`select`大致是相同的，因此也不再花费时间去对它进行总结。 > 相较于`select`而言，由于`poll`内部是基于数组链表构建的，所以没有`select`位图的限制，也就解决了`select`中最多只能监听`1024`个连接的缺陷。同时由于内核返回监听到的事件时，是通过`pollfd.revents`进行传递的，因此`pollfd`是可以被重用的，在下次使用时将`pollfd.revents`置零即可。但对于其他两点缺陷，在`poll`中也依旧存在，不过在`epoll`中却得到了解决，所以接下来重点分析`epoll`实现。 ## 六、多路复用函数 - epoll() `epoll`也是`IO`多路复用模型中最重要的函数，几乎目前绝大部分的高性能框架，都是基于它构建的，例如`Nginx、Redis、Netty`等，所以对于掌握`epoll`知识的必要性显得越发重要。因为在你理解`epoll`之前，你只知道这些技术栈性能很高，但不清楚为什么，而你理解`epoll`之后，对于这些技术栈性能高的原因也就自然就懂了，那接下来我们一起聊聊`epoll`。 `epoll`与之前的`select、poll`函数不同，它整个过程由`epoll_create、epoll_ctl、epoll_wait`三个函数组成，同时最关键的点也在于：`epoll`直接在内核中维护着一个`FD`集合，外部不再需要将整个要监听的`FD`集合拷贝到内核了，而是调用`epoll_ctl`函数进行管理即可。 > 对于Java-NIO中的`JNI`入口，和之前分析的思路相同，因此就不再进行演示，感兴趣的自己根据执行流程，打开相应的目录文件就可以看到。接着重点看看`epoll`系列的函数定义。 ### 6.1、epoll函数定义刚刚聊到过，`epoll`存在三个函数，它们的定义都位于`sys/epoll.h`文件中，那么接下来一个个瞧瞧，先看看`epoll_create`： ```c int epoll_create(int size); int epoll_create1(int flags); ``` 你没看错，`create`函数其实有两个，但对于入参为`size`的函数在很早之前就被弃用了，因此一般调用`create`函数都是在调用`epoll_create1()`，这个函数的作用是申请内核创建一个`epollfd`文件，同时申请一个`eventpoll`结构体（稍后讲），然后返回`epollfd`对应的文件描述符。最后再聊聊它的入参： - `size`：代表指定内核中维护的`FD`集合长度，`2.6.8`版本之后成为了动态集合，被弃用。 - `flags`：这个参数主要有两个传递值： - `0`：正常创建`epollfd`传入的值。 - `EPOLL_CLOEXEC`：当`fork`子进程时，子进程不会包含`epoll`的`fd`（多进程`epoll`时使用）。 --- 了解了`create`函数后，再来看看`epoll_ctl`函数的定义： ```c int epoll_ctl(int epfd, int op, int fd, struct epoll_event* event); ``` 先来说说`ctl`函数的作用吧，这个函数主要就是对于内核维护的`epollfd`集合进行增删改操作，参数释义如下： - `epfd`：表示指定要操作的`epollfd`。 - `op`：表示当前要进行的操作，选项如下： - `EPOLL_CTL_ADD`：注册操作，代表要往内核维护的集合中新增一个`epollfd`。 - `EPOLL_CTL_MOD`：修改操作，代表要更改某个`epollfd`所对应的事件。 - `EPOLL_CTL_DEL`：删除操作，代表要哦承诺内核的集合中移除一个`epollfd`。 - `fd`：表示`epollfd`对应的文件描述符。 - `event`：表示当前描述符的事件队列。 --- 最后看看`epoll_wait`函数的定义： ```c int epoll_wait(int epfd, struct epoll_event* evlist, int maxevents, int timeout); ``` 这个函数的作用就类似于之前的`select、poll`，调用之后会阻塞等待至`I/O`事件发生，参数释义如下： - `epfd`：表示一个等待事件发生的`epollfd`。 - `evlist`：这里用于接收内核已监听到的事件集合。 - `maxevents`：指上述集合出现就绪事件时，一次能够拷贝的最大长度。 - 如果上述集合中的就绪事件小于该值，则一次性全部拷贝过来。 - 如果上述集合中的就绪事件大于该值，则一次最多拷贝`maxevents`个事件。 - `timeout`：这个参数和之前的`select、poll`相同，指定超时时间。 > OK，简单了解三个函数后，大家需牢记的一点是：这三个函数都是配套使用的，遵循上述的顺序，以`create、ctl、wait`这种方式依次进行调用，然后就能对一或多个文件描述符进行监听。当然，对于调用后究竟发生了什么？我们接下来通过源码的方式去揭开面纱。 ### 6.2、epoll的核心结构体在`epoll`中存在两个核心结构体：`epoll_event、eventpoll`，这两个结构体贯穿了`epoll`整个流程，这里先简单看看它们的定义： ```c struct epoll_event { // epoll注册的事件 uint32_t events; // 这个可以理解成epoll要监听的FD详细结构体 epoll_data_t data; } __attribute__ ((__packed__)); // 上述data成员的结构定义 typedef union epoll_data { // 自定义的附带信息，一般传事件的回调函数，当事件发生时， // 通过回调函数将事件添加到list上（Java-Linux-AIO的实现原型） void *ptr; // 要监听的描述符对应 int fd; uint32_t u32; uint64_t u64; } epoll_data_t; ``` 上述的`epoll_event`简单来说，可以将其理解成由“文件描述符-需要监听的事件”组成的键值对结构，其中`data`是文件描述符的详细结构（可以理解成对应着一个FD），而`events`则代表着该`FD`需要监听的事件，这些事件是在调用`epoll_ctl`函数时，由用户态程序指定的，主要有下述一些事件项： - `EPOLLIN`：表示文件描述符可读。 - `EPOLLOUT`：表示文件描述符可写。 - `EPOLLPRI`：表示文件描述符有[带外数据](https://baike.baidu.com/item/%E5%B8%A6%E5%A4%96%E6%95%B0%E6%8D%AE/10059051)可读。 - `EPOLLERR`：表示文件描述符发生错误。 - `EPOLLHUP`：表示文件描述符被挂断。 - `EPOLLET`：将 EPOLL 设为边缘触发(`Edge Trigger`)模式（后续分析）。 - `EPOLLONESHOT`：表示对这个文件描述符只监听一次事件。简单有个概念之后，再来看看另外一个核心结构体`eventpoll`： ```c struct eventpoll { // 这个是一把自旋锁（多线程Epoll时使用） spinlock_t lock; // 这个是一把互斥锁（多线程Epoll时使用） // 添加、修改、删除、监听、返回时都会使用这把锁确保线程安全 struct mutex mtx; // 调用epoll_wait()时, 会在这个等待队列上休眠阻塞 wait_queue_head_t wq; // 这个是用于epollfd本身被poll时使用（一般用不上） wait_queue_head_t poll_wait; // 存储所有I/O事件已经就绪的FD链表 struct list_head rdllist; // 红黑树结构：存放所有需要监听的节点 struct rb_root rbr; // 一个连接着所有树节点的单向链表 struct epitem *ovflist; // 这里保存一些用户变量, 如fd监听数量的最大值等 struct user_struct *user; }; struct epitem { // 红黑树节点（red_black_node的缩写） struct rb_node rbn; // 链表节点，方便存储到eventpoll.rdllist中 struct list_head rdllink; // 下一个节点指针 struct epitem *next; // 当前epitem对应的fd struct epoll_filefd ffd; // 这两个不太懂，似乎跟等待队列有关 int nwait; struct list_head pwqlist; // 当前epitem属于那个eventpoll struct eventpoll *ep; // 链表头 struct list_head fllink; // 当前epitem对应的事件（FD需要监听的事件） struct epoll_event event; }; ``` 在前面提到过，`epoll`舍弃了`select、poll`函数中的思想，不再从用户态全量拷贝`FD`集合到内核，而是自己在内核中维护了一个`FD`集合，而对于`FD`的管理则是基于`eventpoll`结构实现的，`eventpoll`主要负责管理`epoll`事件，在其内部主要有三个成员需要咱们重点关注： - `list_head rdllist`：存放所有`I/O`事件已就绪的列表。 - `rb_root rbr`：用于存放注册时`epollfd`描述符的红黑树结构。 - `wait_queue_head_t wq`：休眠阻塞时的等待队列。当然，对于这个结构体在后续源码中会经常看到，因此稍后会结合源码理解。 ### 6.3、Epoll源码深度历险整个`Epoll`机制由于是三个函数组成的，因此调试源码时则需要依次调试，我们依旧按照`epoll`的调用顺序对其源码进行剖析。 #### 6.3.1、epoll_create()函数源码分析 `epoll_create()`函数对应的系统调用为`SYSCALL_DEFINE1()`，展开后则对应着内核的`sys_epoll_create`函数，如下： ```c SYSCALL_DEFINE1(epoll_create, int, size) { if (size <= 0) return -EINVAL; // 直接调用了create1函数 return sys_epoll_create1(0); } ``` 从上述这点即可看出，为何说`size`入参实际上在后续的版本被弃用了，因为无论传入的`size`等于多少，本质上只会判断一下是否小于`0`，然后就调用了`create1()`函数，入参则被写死为`0`了。接着来看看`sys_epoll_create1()`： ``` SYSCALL_DEFINE1(epoll_create1, int, flags) { int error; struct eventpoll *ep = NULL;//主描述符 // 检查一下常量一致性（没啥用） BUILD_BUG_ON(EPOLL_CLOEXEC != O_CLOEXEC); // 判断一下flags是否传递了CLOEXEC if (flags & ~EPOLL_CLOEXEC) return -EINVAL; // 创建一个eventpoll并为其分配空间，分配出错则直接返回执行错误 error = ep_alloc(&ep); if (error < 0) return error; // 这里是创建一个匿名真实的FD并与eventpoll关联（稍后细聊） error = anon_inode_getfd("[eventpoll]", &eventpoll_fops, ep, O_RDWR | (flags & O_CLOEXEC)); // 如果前面匿名FD创建失败，释放之前为ep分配的空间 if (error < 0) ep_free(ep); // 返回匿名FD或错误码 return error; } static int ep_alloc(struct eventpoll **pep) { int error; struct user_struct *user; struct eventpoll *ep; // 调用kzalloc为ep分配空间 user = get_current_user(); error = -ENOMEM; ep = kzalloc(sizeof(*ep), GFP_KERNEL); if (unlikely(!ep)) goto free_uid; // 对ep的每个成员进行初始化 spin_lock_init(&ep->lock); mutex_init(&ep->mtx); init_waitqueue_head(&ep->wq); init_waitqueue_head(&ep->poll_wait); INIT_LIST_HEAD(&ep->rdllist); ep->rbr = RB_ROOT; ep->ovflist = EP_UNACTIVE_PTR; ep->user = user; *pep = ep; DNPRINTK(3, (KERN_INFO "[%p] eventpoll: ep_alloc() ep=%p\n", current, ep)); return 0; // 分配空间失败时，清空之前的初始化值，返回错误码 free_uid: free_uid(user); return error; } ``` `sys_epoll_create1()`源码也并不复杂，总共就两步： - ①调用`ep_alloc()`函数创建并初始化一个`eventpoll`对象。 - ②调用`anon_inode_getfd()`函数把`eventpoll`对象映射到一个`FD`上，并返回这个`FD`。不过对于第二步，这玩意儿说起来也比较复杂，想深入研究的可以看看 **`Linux`创建匿名FD** 的知识，我们这里就简单的概述一下： > 由于`epollfd`本身在操作系统上并不存在真正的文件与之对应，所以内核需要为其分配一个真正的`struct file`结构，并且能够具备真正的`FD`，然后前面创建出的`eventpoll`对象则会作为一个私有数据保存在`file.private_data`指针上。这样做的目的在于：为了能够通过`FD`找到一个真实的`struct file`，并且能够通过这个`file`找到`eventpoll`对象，然后再通过`eventpoll`找到`epollfd`，从而能够形成一条“关系链”。 #### 6.3.2、epoll_ctl()函数源码分析 `epoll_create()`函数的源码并不复杂，现在紧接着再来看看管理操作`epoll`的`epoll_ctl()`源码实现，这个函数与之对应的系统调用为`SYSCALL_DEFINE4()`，展开后则对应`sys_epoll_ctl()`，下面一起看看： ```c SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd, struct epoll_event __user *, event) { int error; struct file *file, *tfile; struct eventpoll *ep; struct epitem *epi; struct epoll_event epds; // 错误处理动作及从用户空间将epoll_event结构拷贝到内核空间 DNPRINTK(3, (KERN_INFO "[%p] eventpoll: sys_epoll_ctl(%d, %d, %d, %p)\n", current, epfd, op, fd, event)); error = -EFAULT; if (ep_op_has_event(op) && copy_from_user(&epds, event, sizeof(struct epoll_event))) goto error_return; // 通过传入的epfd得到前面创建的真实struct file结构 error = -EBADF; file = fget(epfd); if (!file) goto error_return; // 这里是获取到需要监听的FD对应的真实struct file结构 tfile = fget(fd); if (!tfile) goto error_fput; // 判断一下要监听的目标设备是否实现了poll逻辑 error = -EPERM; if (!tfile->f_op || !tfile->f_op->poll) goto error_tgt_fput; // 判断一下传递的epfd是否有对应的eventpoll对象 error = -EINVAL; if (file == tfile || !is_file_epoll(file)) goto error_tgt_fput; // 根据private_data指针获取其中存放的eventpoll对象（上面聊过的） ep = file->private_data; // 接下来的操作会开始对内核中的结构进行修改，先加锁确保操作安全 mutex_lock(&ep->mtx); // 先从红黑树结构中，根据FD查找一下对应的节点是否存在 epi = ep_find(ep, tfile, fd); error = -EINVAL; // 开始判断用户具体要执行何种操作 switch (op) { // 如果是要注册（向内核添加一个FD） case EPOLL_CTL_ADD: // 先判断之前是否已经添加过一次当前FD if (!epi) { // 如果没有添加，则调用ep_insert()函数将当前fd注册 epds.events |= POLLERR | POLLHUP; error = ep_insert(ep, &epds, tfile, fd); } else // 之前这个FD添加过一次，则返回错误码，不允许重复注册 error = -EEXIST; break; // 如果是删除（从内核中移除一个FD） case EPOLL_CTL_DEL: // 如果前面从红黑树中能找到与FD对应的节点 if (epi) // 调用ep_remove()函数移除相应的节点 error = ep_remove(ep, epi); else // 如果红黑树上都没有FD对应的节点，则无法移除，返回错误码 error = -ENOENT; break; // 如果是修改（修改内核中FD对应的事件） case EPOLL_CTL_MOD: // 和上面的删除同理，调用ep_modify()修改FD对应的节点信息 if (epi) { epds.events |= POLLERR | POLLHUP; error = ep_modify(ep, epi, &epds); } else // 树上没有对应的节点，依旧返回错误码 error = -ENOENT; break; } // 修改完成之后，为了确保其他进程可操作，记得释放锁哦~ mutex_unlock(&ep->mtx); // 这里是对应上述各种错误情况的goto error_tgt_fput: fput(tfile); error_fput: fput(file); error_return: DNPRINTK(3, (KERN_INFO "[%p] eventpoll: sys_epoll_ctl(%d, %d, %d, %p) = %d\n", current, epfd, op, fd, event, error)); return error; } ``` `epoll_ctl()`函数的实现过程，看起来是相当直观明了，总结一下： - ①先将用户传递的`epoll`事件集合`epoll_event`结构从用户空间拷贝到内核。 - ②通过`epfd`找到与之对应的`struct file`结构，再找到`FD`对应的`file`结构。 - ③判断要监听的`FD`设备是否实现了`poll`功能，再根据`private_data`获取`eventpoll`。 - ④上锁，然后通过传入的`fd`在红黑树中查找有没有对应的节点，然后处理用户操作。 - ⑤如果是注册操作，先判断当前`FD`之前是否注册过，在树上是否有相应节点： - 有：代表之前已经添加过一次，不能重复添加，返回错误码。 - 没有：调用`ep_insert()`函数，将当前`FD`添加到红黑树中。 - ⑥如果是删除操作，先看一下树上有没有与目标`FD`对应的节点： - 有：调用`ep_remove()`函数，将当前`FD`对应的节点从树上移除。 - 没有：代表`FD`之前都没有添加过，找不到要移除的节点，返回错误码。 - ⑦如果是修改操作，先看一下树上有没有与目标`FD`对应的节点： - 有：调用`ep_modify()`函数，根据用户的操作项，修改对应节点信息。 - 没有：代表`FD`之前都没有添加过，找不到要修改的节点，返回错误码。 - ⑧操作完成后，释放锁，同时如果前面有错误则利用`goto`处理前面的错误信息。相信认真看一遍源码，以及上述流程后，对于`epoll_ctl()`函数的逻辑就明白了，当然，诸位有些绕的地方估计在`epoll`内部结构之间的关系，上个图理解： ![epoll结构](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e91fa784ecdf407eb4baa2859dd1c2a9~tplv-k3u1fbpfcp-watermark.image?) 整个结构关联起来略显复杂，但如若之前的`epoll_create()`函数真正理解后，其实也并不难懂，调用`epoll_create`后会先创建两个结构体：一个`file`结构、一个`eventpoll`结构，然后会将`eventpoll`保存在`file.private_data`指针中，同时再将这个`file`的文件描述符返回给调用者（用户态程序），此时这个返回的`FD`就是所谓的`epollfd`。然后当我们调用`epoll_ctl()`尝试将一个要监听的`SocketFD`加入到内核时，我们首先需要传递一个`epfd`，而后再`ctl()`函数内部会根据这个`epfd`找到之前创建的`file`结构，再根据其`private_data`指针找到前面创建的`eventpoll`对象，然后定位该对象的内部成员：`rbr`红黑树，在将要监听的`FD`封装成`epitem`节点加入树中。 > 当然，为了求证上述观点，接下来再看看`ep_insert()`函数的实现。 ```c static int ep_insert(struct eventpoll *ep, struct epoll_event *event, struct file *tfile, int fd) { int error, revents, pwake = 0; unsigned long flags; struct epitem *epi; // 这里是一个新的结构体（类似于select、poll中的poll_wqueues结构） struct ep_pqueue epq; // 检查目前是否达到了当前用户进程的最大监听数 if (unlikely(atomic_read(&ep->user->epoll_watches) >= max_user_watches)) return -ENOSPC; // 利用SLAB机制分配一个epitem节点 if (!(epi = kmem_***_alloc(epi_***, GFP_KERNEL))) return -ENOMEM; // 初始化epitem节点的一些成员 INIT_LIST_HEAD(&epi->rdllink); INIT_LIST_HEAD(&epi->fllink); INIT_LIST_HEAD(&epi->pwqlist); epi->ep = ep; // 将要监听的FD以及它的file结构设置到epitem.ffd成员中 ep_set_ffd(&epi->ffd, tfile, fd); epi->event = *event; epi->nwait = 0; epi->next = EP_UNACTIVE_PTR; // 同时开始准备调用fd对应设备的poll epq.epi = epi; // 这里和select、poll差不多，设置执行poll_wait()时， // 其回调函数为ep_ptable_queue_proc(稍后分析) init_poll_funcptr(&epq.pt, ep_ptable_queue_proc); // tfile是需要监听的fd对应的file结构 // 这里就是去调用fd对应设备的poll，询问I/O数据是否可读写 revents = tfile->f_op->poll(tfile, &epq.pt); // 这里是防止执行出现错误的检测动作 error = -ENOMEM; if (epi->nwait < 0) goto error_unregister; // 每个FD会将所有监听自己的epitem链起来 spin_lock(&tfile->f_lock); list_add_tail(&epi->fllink, &tfile->f_ep_links); spin_unlock(&tfile->f_lock); // 上述所有工作完成后，将epitem插入到红黑树中 ep_rbtree_insert(ep, epi); // 判断一下前面调用poll之后，对应设备上的I/O事件是否就绪 if ((revents & event->events) && !ep_is_linked(&epi->rdllink)) { // 如果已经就绪，那直接将当前epitem节点添加到eventpoll.rdllist中 list_add_tail(&epi->rdllink, &ep->rdllist); // 同时唤醒正在阻塞等待的进程 if (waitqueue_active(&ep->wq)) wake_up_locked(&ep->wq); if (waitqueue_active(&ep->poll_wait)) pwake++; } spin_unlock_irqrestore(&ep->lock, flags); atomic_inc(&ep->user->epoll_watches); // 调用poll_wait()执行回调函数（为了防止锁资源占用，这是在锁外调用） if (pwake) ep_poll_safewake(&ep->poll_wait); return 0; // 执行出错的goto代码块 error_unregister: ep_unregister_pollwait(ep, epi); spin_lock_irqsave(&ep->lock, flags); if (ep_is_linked(&epi->rdllink)) list_del_init(&epi->rdllink); spin_unlock_irqrestore(&ep->lock, flags); kmem_***_free(epi_***, epi); return error; } ``` 其实对于`ep_insert()`这个函数呢，说清楚来也并不复杂，简单总结一下： - ①对于要监听的`FD`会先分配一个`epitem`节点，并且根据`FD`对节点进行初始化。 - ②最开始声明了一个结构体`ep_pqueue`，然后会利用它为`FD`设置`poll_wait`回调函数。 - ③尝试调用`FD`对应设备的`poll`，询问当前`FD`的`I/O`数据是否可被读写。 - ④调用`ep_rbtree_insert()`函数将已经构建好的`epitem`节点插入红黑树中。 - ⑤判断一下当前`FD`的`I/O`事件是否已就绪（可被读写），如果可以则唤醒等待的进程。当然，对于新的结构体`ep_pqueue`，它的功能和之前聊到的`poll_wqueues`功能大致相同，主要用于设置唤醒回调，定义如下： ```c struct ep_pqueue { poll_table pt; struct epitem *epi; }; ``` 很明显就可以看出，与`poll_wqueues`结构中同样存在`poll_table`成员，不熟悉的跳回之前讲`poll_wqueues`的环节。不过`Epoll`与`Select、Poll`还是存在些许不同的，在之前设置`poll_wait()`的回调函数是`__pollwait()`，但在这里设置的确是`ep_ptable_queue_proc()`函数，那这个函数会做什么事情呢？来看看： ```c static void ep_ptable_queue_proc(struct file *file, wait_queue_head_t *whead, poll_table *pt) { struct epitem *epi = ep_item_from_epqueue(pt); struct eppoll_entry *pwq; if (epi->nwait >= 0 && (pwq = kmem_***_alloc(pwq_***, GFP_KERNEL))) { // 初始化等待队列, 指定ep_poll_callback为唤醒时的回调函数 init_waitqueue_func_entry(&pwq->wait, ep_poll_callback); pwq->whead = whead; pwq->base = epi; // 将节点加入到等待队列中..... add_wait_queue(whead, &pwq->wait); list_add_tail(&pwq->llink, &epi->pwqlist); epi->nwait++; } else { /* We have to signal that an error occurred */ epi->nwait = -1; } } ``` 上述重心我们只需要知道一个点，这个函数会在执行`f_op->poll`时被调用的，在这里最重要的是设置了一个唤醒时的回调函数`ep_poll_callback()`，也就是当某个设备上`I/O`事件就绪后，唤醒进程时会调用的函数，实现如下： ```c static int ep_poll_callback(wait_queue_t *wait, unsigned mode, int sync, void *key) { int pwake = 0; unsigned long flags; // 从等待队列获取epitem节点（主要目的在于要确认哪个进程在等待当前设备就绪） struct epitem *epi = ep_item_from_wait(wait); // 获取当前epitem节点所在的eventpoll struct eventpoll *ep = epi->ep; spin_lock_irqsave(&ep->lock, flags); if (!(epi->event.events & ~EP_PRIVATE_BITS)) // 检测错误 goto out_unlock; // 检测目前设备上就绪的事件是否为我们要监听的事件 if (key && !((unsigned long) key & epi->event.events)) // 如果不是，则直接跳转goto goto out_unlock; // 这里是用来处理事件并发出现时的情况， // 假设当前的回调方法被执行，但epoll_wait()已经获取到了别的IO事件， // 那么此时将当前设备发生的事件，epitem会用一个链表存储， // 此时不立即发给应用程序，也不丢弃本次IO事件， // 而是等待下次调用epoll_wait()函数时返回 if (unlikely(ep->ovflist != EP_UNACTIVE_PTR)) { if (epi->next == EP_UNACTIVE_PTR) { epi->next = ep->ovflist; ep->ovflist = epi; } // 然后直接跳转goto goto out_unlock; } // 正常情况下，将当前已经触发IO事件的epitem节点放入readylist就绪列表 if (!ep_is_linked(&epi->rdllink)) list_add_tail(&epi->rdllink, &ep->rdllist); // 唤醒调用epoll_wait后阻塞的进程... if (waitqueue_active(&ep->wq)) wake_up_locked(&ep->wq); // 如果epollfd也在被poll, 也唤醒队列里面的所有成员(多进程epoll情况) if (waitqueue_active(&ep->poll_wait)) pwake++; // 前面的goto跳转处理 out_unlock: spin_unlock_irqrestore(&ep->lock, flags); if (pwake) ep_poll_safewake(&ep->poll_wait); return 1; } ``` 这个唤醒回调函数，主要干的事情就是处理了几种特殊情况，然后将`IO`事件就绪的节点添加到了`eventpoll.readylist`就绪列表，紧接着唤醒了调用`epoll_wait()`函数后阻塞的进程。 > 至此，`epoll_ctl()`函数调用后，会执行的流程就已经分析明白了。当然，对于具体如何插入、移除、修改节点的函数就不分析了，这里就是红黑树结构的知识，大家可参考`HashMap`集合的元素管理原理。接下来重点看看`epoll_wait()`函数。 #### 6.3.3、epoll_wait()函数源码分析 `epoll_wait()`也是整个`Epoll`机制中最重要的一步，前面的`create、ctl`函数都仅仅是在为`wait`函数做准备工作，`epoll_wait()`是一个阻塞函数，调用后会导致当前程序发生阻塞等待，直至获取到有效的`IO`事件或超时为止。 `epoll_wait()`对应的系统调用为`SYSCALL_DEFINE4()`函数，展开后则是`sys_epoll_wait()`，不多说直接上源码： ```c SYSCALL_DEFINE4(epoll_wait, int, epfd, struct epoll_event __user *, events, int, maxevents, int, timeout) { int error; struct file *file; struct eventpoll *ep; // 获取的最大事件数量必须大于0，并且不超出ep的最大事件数 if (maxevents <= 0 || maxevents > EP_MAX_EVENTS) return -EINVAL; // 内核会验证用户接收事件的这一段内存空间是不是有效的. if (!access_ok(VERIFY_WRITE, events, maxevents * sizeof(struct epoll_event))) { error = -EFAULT; goto error_return; } error = -EBADF; // 根据epollfd获取对应的struct file真实文件 file = fget(epfd); if (!file) goto error_return; error = -EINVAL; // 检查一下获取到的file是不是一个epollfd if (!is_file_epoll(file)) goto error_fput; // 获取file的private_data数据，也就是根据file获取eventpoll对象 ep = file->private_data; // 获取到eventpoll对象调用ep_poll()函数（这个是核心函数！） error = ep_poll(ep, events, maxevents, timeout); error_fput: fput(file); error_return: return error; } ``` 上述逻辑也不难，首先对于用户态调用`epoll_wait()`函数时传递的一些参数进行了效验，因为内核对于进程采取的态度是绝对不信任，因此对于用户进程递交的任何参数都会进行效验，确保无误后才会采取下一步措施。当上述代码前面效验了参数的“合法性”后，又根据`epfd`获取了对应的`file`，然后又根据`file`获取到了`eventpoll`对象，最后调用了`ep_poll()`函数并传入了`eventpoll`对象，再看看这个函数： ```c static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events, int maxevents, long timeout) { int res, eavail; unsigned long flags; long jtimeout; // 等待队列 wait_queue_t wait; // 如果调用epoll_wait时传递了阻塞时间，那么先计算休眠时间, // 毫秒要转换为HZ电磁波动的频率（比较严谨，控制的非常精细） jtimeout = (timeout < 0 || timeout >= EP_MAX_MSTIMEO) ? MAX_SCHEDULE_TIMEOUT : (timeout * HZ + 999) / 1000; retry: spin_lock_irqsave(&ep->lock, flags); res = 0; // 判断一下eventpoll.readylist事件就绪列表是否为空 if (list_empty(&ep->rdllist)) { // 初始化等待队列，准备将当前进程挂起阻塞 init_waitqueue_entry(&wait, current); // 挂载到如果eventpoll.wq等待队列中 __add_wait_queue_exclusive(&ep->wq, &wait); // 核心循环！ for (;;) { // 准备进入阻塞，先将当前进程设置为睡眠状态(可被信号唤醒) set_current_state(TASK_INTERRUPTIBLE); // 如果睡眠之前，readylist中有数据了或已经到了给定的超时事件 if (!list_empty(&ep->rdllist) || !jtimeout) break; // 不睡了，直接中断循环 // 如果出现唤醒信号，也中断循环，不睡了退出干活 if (signal_pending(current)) { res = -EINTR; break; } // 上述的几个情况都未发生，在这里准备正式进入睡眠状态 spin_unlock_irqrestore(&ep->lock, flags); // 开始睡觉(如果指定了阻塞时间，jtimeout时间过后会自动醒来) jtimeout = schedule_timeout(jtimeout); // 正式进入睡眠阻塞 spin_lock_irqsave(&ep->lock, flags); } // 出现唤醒信号、或事件已就绪、或已超时，则将进程从等待队列移除 __remove_wait_queue(&ep->wq, &wait); // 这里设置一下当前进程的状态为运行状态（活跃状态） set_current_state(TASK_RUNNING); } // 因为超时的情况下当前进程也会醒来，所以这里需要再次判断一下： // 目前到底是否已经有数据就绪了，这里会返回一个布尔值给 eavail eavail = !list_empty(&ep->rdllist) || ep->ovflist != EP_UNACTIVE_PTR; spin_unlock_irqrestore(&ep->lock, flags); // 如果确定有事件发生，那则调用ep_send_events()将事件拷贝给用户进程 if (!res && eavail && !(res = ep_send_events(ep, events, maxevents)) && jtimeout) goto retry; // 最后返回本次监听到的事件数 return res; } ``` 上述的`ep_poll()`函数，对比`select、poll`而言要简单很多，整个流程也没几步： - ①转换给定的阻塞时间，并判断就绪列表中事件是否已就绪，没有则准备休眠阻塞。 - ②先初始化等待队列并挂载到`eventpoll.wq`中，然后进入循环，设置进程的状态。 - ③在正式进入睡眠之前，再次检测是否有事件就绪、是否已超时、是否出现唤醒信号。 - ④如果都没有出现，则调用`schedule_timeout(jtimeout)`函数让进程睡眠一定时间。 - ⑤当睡眠超时、或出现唤醒信号、或事件已就绪，将当前进程从队列移除并设置运行状态。 - ⑥有事件到来非超时的情况下，则调用`ep_send_events()`将就绪事件拷贝给用户进程。 OK~，上述总结的流程已经描述的十分清晰了，接下来再看看拷贝就绪事件的函数`ep_send_events()`： ```c static int ep_send_events(struct eventpoll *ep, struct epoll_event __user *events, int maxevents) { struct ep_send_events_data esed; // 获取用户进程传递的maxevents值 esed.maxevents = maxevents; // 获取用户态存放就绪事件的集合 esed.events = events; // 调用ep_scan_ready_list()函数进行具体处理 return ep_scan_ready_list(ep, ep_send_events_proc, &esed); } ``` 这个函数非常简单，一眼看明白了，其实最终的拷贝工作是由`ep_scan_ready_list()`完成的，那么再来看看它： ```c static int ep_scan_ready_list(struct eventpoll *ep, int (*sproc)(struct eventpoll *, struct list_head *, void *), void *priv) { int error, pwake = 0; unsigned long flags; struct epitem *epi, *nepi; LIST_HEAD(txlist); // 先上锁，防止出现安全问题 mutex_lock(&ep->mtx); spin_lock_irqsave(&ep->lock, flags); // 将rdllist中所有就绪的节点转移到txlist，然后清空rdllist list_splice_init(&ep->rdllist, &txlist); ep->ovflist = NULL; spin_unlock_irqrestore(&ep->lock, flags); // sproc是前面调用当前函数时传递的ep_send_events_proc()， // 会通过这个函数处理每个epitem节点 error = (*sproc)(ep, &txlist, priv); spin_lock_irqsave(&ep->lock, flags); // 之前曾讲到过，如果epoll正在拷贝数据时又发生了IO事件， // 那么则会将这些IO事件保存在ovflist组成一个链表，现在来处理这些事件 for (nepi = ep->ovflist; (epi = nepi) != NULL; nepi = epi->next, epi->next = EP_UNACTIVE_PTR) { // 将这些直接放入readylist列表中 if (!ep_is_linked(&epi->rdllink)) list_add_tail(&epi->rdllink, &ep->rdllist); } ep->ovflist = EP_UNACTIVE_PTR; // 上一次没有处理完的epitem节点, 重新插入到readylist // 因为epoll一次只能拷贝maxevents个事件返回用户态 list_splice(&txlist, &ep->rdllist); // readylist不为空, 直接唤醒 if (!list_empty(&ep->rdllist)) { // 唤醒的前置工作 if (waitqueue_active(&ep->wq)) wake_up_locked(&ep->wq); if (waitqueue_active(&ep->poll_wait)) pwake++; } spin_unlock_irqrestore(&ep->lock, flags); mutex_unlock(&ep->mtx); // 为了防止长时间占用锁，在锁外执行唤醒工作 if (pwake) ep_poll_safewake(&ep->poll_wait); return error; } ``` 流程就不写了，源码中标注的很清楚，下面再来看看`ep_send_events_proc()`函数是如何处理每个`epitem`节点的： ```c // 注意点：这里的入参list_head并不是readylist，而是上面函数的txlist static int ep_send_events_proc(struct eventpoll *ep, struct list_head *head, void *priv) { struct ep_send_events_data *esed = priv; int eventcnt; unsigned int revents; struct epitem *epi; struct epoll_event __user *uevent; // 先用循环扫描整个列表（不一定会全部处理，最多只处理maxevents个） for (eventcnt = 0, uevent = esed->events; !list_empty(head) && eventcnt < esed->maxevents;) { // 依次获取到其中的一个epitem节点 epi = list_first_entry(head, struct epitem, rdllink); // 紧接着从列表中将这个节点移除 list_del_init(&epi->rdllink); // 再次读取当前节点对应FD所触发的事件，其实在唤醒回调函数中， // 这个工作也执行过一次，那为啥这里还需要做一次呢？ // 答案是：为了确保读到最新的事件，因为有些FD可能前面触发了读就 // 绪事件，后面又触发了写就绪事件，因此这里要确保严谨性。 revents = epi->ffd.file->f_op->poll(epi->ffd.file, NULL) & epi->event.events; if (revents) { // 调用__put_user将就绪的事件拷贝至用户进程传递的事件集合中 if (__put_user(revents, &uevent->events) || __put_user(epi->event.data, &uevent->data)) { list_add(&epi->rdllink, head); return eventcnt ? eventcnt : -EFAULT; } eventcnt++; uevent++; if (epi->event.events & EPOLLONESHOT) epi->event.events &= EP_PRIVATE_BITS; else if (!(epi->event.events & EPOLLET)) { // 大名鼎鼎的ET和LT，就在这一步会有不同（稍后分析） list_add_tail(&epi->rdllink, &ep->rdllist); } } } return eventcnt; } ``` 处理每个`epitem`节点的函数中，重点就做了两件事： - ①读取了每个`epitem`节点最新的就绪事件。 - ②调用`__put_user()`函数将就绪的事件拷贝至用户进程传递的`evlist`集合中。至此，`epoll_wait()`函数的核心源码也全都走了一遍，最后来简单的总结一下。 #### 6.3.4、Epoll被阻塞的进程是如何唤醒的？到这里，大家应该有个疑惑：`epoll_wait()`函数中，本质上只做了进程休眠阻塞的工作，那它什么时候会被唤醒呢？先对于这个点回答一下：大家还记得前面分析`epoll_ctl()`函数时，在其中调用了每个`FD`的`poll`吗？ > `revents = tfile->f_op->poll(tfile, &epq.pt);` 也就是这行代码，在调用`epoll_ctl()`函数向内核插入一个节点时，就会先询问一次`FD`的`IO`数据是否可被读写，此时如果可以就会直接将这个节点添加到`readylist`列表中，但如果对应驱动设备的`IO`事件还未就绪，则会将当前进程注册到每个`FD`对应设备的等待队列上，并设置唤醒回调函数为`ep_poll_callback()`。这样也就意味着，如果某个`FD`的事件就绪了，就会由对应的驱动设备执行这个回调，在`ep_poll_callback()`函数中，会先将对应的节点先插入到`readylist`列表，然后会尝试唤醒`eventpoll`等待队列中阻塞的进程。当后续调用`epoll_wait()`函数时，会先判断`readylist`列表中是否有事件就绪，如果有就直接读取返回了，如果没有则会让当前进程阻塞休眠，并将当前进程添加到`eventpoll`等待队列中，然后某个`FD`的数据就绪后，则会唤醒这个队列中阻塞的进程，此时调用`epoll_wait()`陷入阻塞的进程就被唤醒工作了！！发现没有，`Epoll`的源码设计中是环环相扣的，十分巧妙！ > OK~，搞清楚这点之后，`Epoll`的核心逻辑已经讲完了十之八九，还剩下`Epoll`的两种事件触发机制未讲到，来聊一聊吧。 ### 6.4、Epoll的两种事件触发机制相信之前有简单了解过`Epoll`的小伙伴都明白，在`Epoll`中有两种事件触发模式，分别被称为水平触发与边缘触发，一般来说，边缘触发的性能远超于水平触发。 #### 6.4.1、Epoll水平触发机制-LT模式 `LT`模式也是`Epoll`的默认事件触发机制，也就是当某个`FD`（`epitem`节点）被处理后，如果还依旧存在事件或数据，则会再次将这个`epitem`节点加入`readylist`列表中，当下次调用`epoll_wait()`时依旧会返回给用户进程。 > 大家还记得前面分析`ep_send_events_proc()`函数时，最后的那两行代码吗？ ```c else if (!(epi->event.events & EPOLLET)) { list_add_tail(&epi->rdllink, &ep->rdllist); } ``` 在这个函数中，最后面做了一个简单的判断，如果当前`Epoll`的工作模式没有设置成`EL`，同时当前节点还有事件未处理，就会调用`list_add_tail()`函数将当前的`epitem`节点重新加入`readylist`列表。反之，`ET`模式下则不会这么做。 #### 6.4.2、Epoll边缘触发机制-ET模式在`ET`模式中，就是和`LT`模式反过来的，当处理一个`epitem`节点时，就算其中还有事件没处理完，那我也不会将这个节点重新加入`readylist`列表，除非这个节点对应的`FD`又再次触发了新事件，然后再次执行了`ep_poll_callback()`回调函数，此时才会将其重新加入到`readylist`。 > 说人话简单一点：就是`ET`模式下，对于当前触发的事件，只会通知用户进程一次，就算没有处理也不会重复通知，除非这个`FD`发生新的事件。而`LT`模式下则相反，无论何种情况下都能确保事件不丢失。那又该如何设置`ET`触发机制呢？其实也就是在调用`epoll_ctl()`函数时，指定感兴趣的监听事件时，多加一个`EPOLLET`即可。 > 基于`Epoll`机制构建的大部分高性能应用，一般都会采用`ET`模式，例如`Nginx`。 ### 6.5、Epoll小结与一个争议的问题相较于之前的`select`函数存在的四个问题，在`Epoll`中得到了合理解决，但也并非`Epoll`的性能就一定比`Select、Poll`要好，在监听的文件描述符较少、且经常更换监听的目标`FD`的情况下，`Select、Poll`的性能反而会更佳。 > 当然，`epoll`在高并发的性能下，会有非常优异的表现，这是由于多方面原因造就的，比如在内核中维护`FD`避免反复拷贝切换、对于就绪事件回调通知，无需用户进程再次轮询查找、内部采用红黑树结构维护节点、退出`ET`事件触发机制等....... 同时对于网上一个较为争议的问题：**`Epoll`到底有没有试用`MMAP`共享内存呢**？从`Epoll`源码的角度来看，其实是并未使用的，在向用户进程返回就绪事件时，本质上是调用了`__put_user()`函数将数据从内核拷贝到了用户态。当然，我`Epoll`的源码是基于内核`3.x`版本的，但听网上说在早版本里面用到了，但翻阅分析`select`源码时用的内核`2.6`版本源码，在里面`Epoll`都还未定义完整，仅有部分实现，所以也没有发现`mmap`相关的`API`调用。 > 不过在`Java-NIO`的`FileChannel.transferTo()`方法中，以及在`Linux`系统的`sendfile()`函数中确实用到了，因此操作本地文件数据时，确实会用到`mmap`共享内存。因此，`Java-NIO`中用到了`mmap`，但`Epoll`中应该未曾用到。 ## 七、多路复用模型总结看到到这里，也就接近尾声了，上面已经对于`Linux`系统下提供的多路复用函数进行了全面深入剖析，大家反复阅读几遍，自然能够彻底弄懂`select、poll、epoll`这些函数的工作原理。 > 不过对于`Epoll`的分析还有一些内容未曾提及，也就是`Epoll`唤醒时的惊群问题，大家感兴趣的可自行去研究，这里只埋下一个引子，当然也并不复杂。而整个`Java-NIO`都是基于底层的多路复用函数构建的，但本篇仅分析了`Linux`系统下的多路复用实现，在本文开篇也提到过：`JVM`为了维持自己的跨平台性，因此在不同的系统下会分别调用不同的多路复用函数，比如`Windows-Select、Mac-KQueue`函数，其中`Windows-Select`与`Linux-Select`的实现类似，因此我从`JNI`调用的入参上来说大致相同。而`Mac-KQueue`则与`Linux-Epoll`类似。但对于其内部实现我并不清楚，毕竟是闭源的系统，大家有兴趣可以自行研究。 > 最后，还有`Java-AIO`的内容，其底层是如何实现的呢？在异步非阻塞式`IO`的支持方面，`Windows`系统反而做的更好，因为它有专门实现`IOCP`机制，但`Linux、Mac`系统则是通过`KQueue、Epoll`模拟实现的。至此，最后也简单的总结一下本篇分析的`select、poll、epoll`三者之间的区别：对比项 | Select | Poll | Epoll :-:|:-:|:-:|:-: 内部数据结构 | 数组位图 | 数组链表 | 红黑树最大监听数 | 1024 | 理论无限制 | 理论无限制事件查找机制 | 线性轮询 | 线性轮询 | 回调事件直接写回用户态事件处理时间复杂度 | O(n) | O(n) | O(1) 性能对比 | `FD`越多越差| `FD`越多越差| `FD`增多不会造成影响 `FD`传递机制 | 用~核拷贝 | 用~核拷贝 | 内核维护结构 `......`，除上述之外，三者还存在很多细微差异，大家认真看懂本篇自然能心中明了，因此不再赘述，到此为本文画上句号。 > 本文由于整篇涉及到`Linux`内核源码的调试，由于自己本身不是`C`开发，所以调试起来也显得心里憔悴，但至少对于多路复用函数的核心源码都已阐明。当然，如若文中存在不足还请谅解，对于存在误区、疑义的地方也欢迎留言指正。最后，也希望大家动动手指点赞支持，在此万分感谢`^_^`