导言

select/poll、epoll这些词汇信任诸位都不生疏，由于在Redis/Nginx/Netty等一些高功能技术栈的底层原理中，咱们应该都见过它们的身影，接下来要点解说这块内容，不过在此之前，先上一张图概述Java-NIO的全体结构：

(八)Java网络编程之IO模型篇-内核Select、Poll、Epoll多路复用函数源码深度历险！

调查上述结构，其实Buffer、Channel的界说并不算杂乱，仅是单纯的三层结构，因而关于源码这块不再去剖析，有爱好的依据给出的目录结构去调试源码，天然也能摸透其原理完结。

而最要害的是Selector选择器，它是整个NIO体系中较为杂乱的一块内容，一同它也作为Java-NIO与内核多路复用模型的“中心者”，但在上述体系中，却呈现了之前未曾提及过的SelectorProvider系界说，那么它的效果是干嘛的呢？首要意图是用于创立选择器，在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()办法去监听事情是否被触发，如下：

// 轮询监听选择器上注册的通道是否有事情被触发
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()办法，如下：

// 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()触发实在的逻辑操作，接下来再看看这个办法：

// 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（这里看或许有些懵，但待会剖析往后就了解了）。

在这个进程中，最最最要害点在于其间的一行代码：

this.subSelector.poll();

在这里调用了poll办法，履行详细的事情拉取逻辑，进一步往下走：

// 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运转时数据区-本地办法栈》的文章提到过，当程序履行时碰到native要害字润饰的办法时，会调用C/C++所编写的本地办法库中的完结，那么又该怎么查找native办法对应的源码呢？接着一同来聊一下。

①由于Oracle-jdk是收费的，所以咱们首要下载open-jdk1.8的源码，能够自行在Open-JDK官网下载，但官网下载时，常常会由于网络不稳定而中止，下载起来相当费劲，因而也为咱们供给一下《open-jdk1.8》的源码链接。

②下载之后解压源码包，然后进入jdk8-master\jdk\src\目录，在其间你会看到不同操作体系下的Java完结，JDK源码会以操作体系的类型分包，不同体系的对应不同的完结，如下：

(八)Java网络编程之IO模型篇-内核Select、Poll、Epoll多路复用函数源码深度历险！

但关于Linux体系下的Java-NIO完结，实践上并不在linux目录中，而是在solaris目录，进入solaris目录如下：
(八)Java网络编程之IO模型篇-内核Select、Poll、Epoll多路复用函数源码深度历险！

solaris目录中还包含了LinuxOS、SunOS(SolarisOS/UnixOS)以及MacOS等操作体系下的Java-NIO完结，但关于MacOS下的Java-NIO完好完结，则坐落前面的macosx目录中，这里仅包含一部分，结构如下：
(八)Java网络编程之IO模型篇-内核Select、Poll、Epoll多路复用函数源码深度历险！

调查上图会发现，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为例：

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办法源码后，其间存在这么一行：

(八)Java网络编程之IO模型篇-内核Select、Poll、Epoll多路复用函数源码深度历险！

调查之后不难发现，其实终究还会调用到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对文件进行操作，关于文件描述符这个概念能够经过一个例子来了解：

Object obj = new Object();

上述是Java创立方针的一行代码，类比Linux的文件体系，后边new Object()实例化出来的方针能够当成是详细的文件内容，而前面的引用obj则可了解为是文件描述符。Linux经过FD操作文件，其实本质上与Java中经过reference引用操作方针的进程无异。

而当呈现网络套接字衔接时，悉数的网络衔接都会以文件描述符的办法在内核中存在，也包含后边会提及的多路复用函数select、poll、epoll都会依据FD对网络衔接进行操作，因而先说明这点，作为后续剖析的根底。

3.2、自己规划网络衔接服务器

在剖析之前，咱们先自己设想一下，如果有个需求：请自己规划一套网络衔接体系，那么此刻你会怎么做呢？此刻例如来了5个网络衔接，如下：

(八)Java网络编程之IO模型篇-内核Select、Poll、Epoll多路复用函数源码深度历险！

那么又该怎么处理这些恳求呢？最简略的办法：
(八)Java网络编程之IO模型篇-内核Select、Poll、Epoll多路复用函数源码深度历险！

关于每个到来的网络衔接都为其创立一条线程，每个衔接由独自的线程担任处理，所以开端的BIO也是这样来的，由于规划起来十分简略，所以它成为了开端的网络IO模型，但这种办法的缺点十分显着，在之前的BIO章节也曾剖析过，无法支撑高并发的流量访问，因而这种多线程的办法去完结天然行不通了，兜兜转转又得回到单线程的视点去考虑，单线程怎么处理多个网络恳求呢？最简略的办法，伪代码如下：

// 不断轮询监听悉数的网络衔接
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版别内核源码》解压调试。

先讲清楚接下来的剖析思路，在后续剖析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中的界说如下：

// 界说坐落/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，先来看看它们是怎么界说的：

// 相关界说坐落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则代表有事情触发，如下图：

(八)Java网络编程之IO模型篇-内核Select、Poll、Epoll多路复用函数源码深度历险！

在这个数组中，悉数的long元素，在核算机底层本质上都会被转换成bit存储，而每一个bit位都对应着一个FD，所以这个数组本质上就组成了一个位图结构，一同为了便利操作这个位图，在之前的sys/select.h文件中还供给了一组宏函数，如下：

// 坐落/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结构体是怎么界说的：

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()的五个参数。

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()函数的运用进程：

/* ----------①---------- */
// 创立服务端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调用为例，其实大体的进程也是相同的，如下：

(八)Java网络编程之IO模型篇-内核Select、Poll、Epoll多路复用函数源码深度历险！

没有下载到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，那它究竟是什么意思呢？先来看看它的界说：

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()，其完结如下：

// 调用了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()吧，先上源码：

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()函数中的一个中心结构，界说如下：

// 坐落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/，如下：

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()函数：

// 坐落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相差不大，准确来说，悉数的多路复用函数界说都差不多，如下：

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，其界说如下：

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()函数，但先来看看前面的函数完结：

// 坐落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 = &current_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，那么再来看看这个，源码完结如下：

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，界说如下：

struct poll_list {
    struct poll_list *next;
    int len;
    struct pollfd entries[0];
};

从上述结构体的成员很显着就可看出，这是一个典型的单向的数组链表结构，第一个成员代表下一个节点（数组链表）是谁，第二个成员代表后边可变长数组的元素数量，第三个成员则是一个变长数组，里边寄存当时这段内存上的pollfd。

关于这个变长数组咱们会存在少许疑问，明明上面界说的长度为[0]，为何能够变长呢？这是运用到了C言语里的数组拓展技术，感爱好的可点击>>这里<<详细了解。

一同，关于“数组链表结构”咱们或许有少许疑问，链表、数组这是两个结构，为何会被组合在一块呢？这是由于poll中，会先选用栈上分配的办法存储pollfd，可是当用户态传入的pollfd过多时，栈上内存或许不太够用，因而就会调用kmalloc分配新的内存，而前面剖析select时提过：kmalloc分配的新空间是依据堆内存的，所以此刻poll就会一同运用多块内存，示意图如下：

(八)Java网络编程之IO模型篇-内核Select、Poll、Epoll多路复用函数源码深度历险！

也便是说：如果栈上能存储用户空间传递的pollfd，那么只会呈现一个poll_list在栈上，如果存储不下则会有多个，除开第一个数组外，其他的都在堆上，因而poll_list结构中的指针会指向其他一个数组。

OK~，弄了解了poll_list结构体后，关于do_sys_poll函数的履行流程就不再重复了，咱们可参考我源码中给出的补白，下面直入主题，一同来看看do_poll()函数会做什么作业：

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函数的完结放出来：

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：

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函数的界说：

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函数的界说：

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整个流程，这里先简略看看它们的界说：

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：表明文件描述符有带外数据可读。
  • EPOLLERR：表明文件描述符产生过错。
  • EPOLLHUP：表明文件描述符被挂断。
  • EPOLLET：将 EPOLL 设为边际触发(Edge Trigger)办法（后续剖析）。
  • EPOLLONESHOT：表明对这个文件描述符只监听一次事情。

简略有个概念之后，再来看看其他一个中心结构体eventpoll：

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函数，如下：

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()，下面一同看看：

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内部结构之间的关系，上个图了解：

(八)Java网络编程之IO模型篇-内核Select、Poll、Epoll多路复用函数源码深度历险！

整个结构相关起来略显杂乱，但如若之前的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()函数的完结。

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功能大致相同，首要用于设置唤醒回调，界说如下：

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()函数，那这个函数会做什么事情呢？来看看：

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事情安排妥当后，唤醒进程时会调用的函数，完结如下：

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()，不多说直接上源码：

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方针，再看看这个函数：

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()：

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()完结的，那么再来看看它：

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节点的：

// 留意点：这里的入参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()函数时，终究的那两行代码吗？

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开发，所以调试起来也显得心里憔悴，但至少关于多路复用函数的中心源码都已说明。当然，如若文中存在缺乏还请体谅，关于存在误区、疑义的当地也欢迎留言纠正。终究，也希望咱们动动手指点赞支撑，在此万分感谢^_^