<返回更多

彻底搞懂epoll高效运行的原理

2020-11-04    
加入收藏

前言

这篇文章读不懂的没关系，可以先收藏一下。笔者准备介绍完epoll和NIO等知识点，然后写一篇JAVA网络IO模型的介绍，这样可以使Java网络IO的知识体系更加地完整和严谨。初学者也可以等看完IO模型介绍的博客之后，再回头看这些博客，会更加有收获。

如果你顺利啃下这篇博客，恭喜你，Nginx、redis和NIO等核心思想已经被你掌握了，可以顺势去拓展自己的理解。否则，只是孤立的看epoll，时间一长会很快忘记的。

当然，这些核心思想，笔者也会在之后的博客慢慢做详细讲解，欢迎关注

概念初探

epoll是一种I/O事件通知机制，是linux 内核实现IO多路复用的一个实现。

IO多路复用是指，在一个操作里同时监听多个输入输出源，在其中一个或多个输入输出源可用的时候返回，然后对其的进行读写操作。

IO多路复用，以后的博客会有详细讲解。

I/O

输入输出(input/output)的对象可以是文件(file)， 网络(socket)，进程之间的管道(pipe)。在linux系统中，都用文件描述符(fd)来表示。

事件

通知机制

通知机制，就是当事件发生的时候，则主动通知。通知机制的反面，就是轮询机制。

epoll的通俗解释

结合以上三条，epoll的通俗解释是一种当文件描述符的内核缓冲区非空的时候，发出可读信号进行通知，当写缓冲区不满的时候，发出可写信号通知的机制

epoll的API详解

epoll的核心是3个API，核心数据结构是：1个红黑树和1个链表

彻底搞懂epoll高效运行的原理

 

epoll

1. int epoll_create(int size)

功能：

size参数表示所要监视文件描述符的最大值，不过在后来的Linux版本中已经被弃用（同时，size不要传0，会报invalid argument错误）

2. int epoll_ctl(int epfd， int op， int fd， struct epoll_event *event)

功能：

typedef union epoll_data {
 void *ptr; /* 指向用户自定义数据 */
 int fd; /* 注册的文件描述符 */
 uint32_t u32; /* 32-bit integer */
 uint64_t u64; /* 64-bit integer */
} epoll_data_t;
struct epoll_event {
 uint32_t events; /* 描述epoll事件 */
 epoll_data_t data; /* 见上面的结构体 */
};

对于需要监视的文件描述符集合，epoll_ctl对红黑树进行管理，红黑树中每个成员由描述符值和所要监控的文件描述符指向的文件表项的引用等组成。

op参数说明操作类型：

struct epoll_event结构描述一个文件描述符的epoll行为。在使用epoll_wait函数返回处于ready状态的描述符列表时，

常用的epoll事件描述如下：

3. int epoll_wait(int epfd， struct epoll_event *events， int maxevents， int timeout);

功能：

处于ready状态的那些文件描述符会被复制进ready list中，epoll_wait用于向用户进程返回ready list。events和maxevents两个参数描述一个由用户分配的struct epoll event数组，调用返回时，内核将ready list复制到这个数组中，并将实际复制的个数作为返回值。注意，如果ready list比maxevents长，则只能复制前maxevents个成员；反之，则能够完全复制ready list。

另外，struct epoll event结构中的events域在这里的解释是：在被监测的文件描述符上实际发生的事件。

参数timeout描述在函数调用中阻塞时间上限，单位是ms：

epoll的两种触发方式

epoll监控多个文件描述符的I/O事件。epoll支持边缘触发(edge trigger，ET)或水平触发（level trigger，LT)，通过epoll_wait等待I/O事件，如果当前没有可用的事件则阻塞调用线程。

select和poll只支持LT工作模式，epoll的默认的工作模式是LT模式。

1.水平触发的时机

  1. 对于读操作，只要缓冲内容不为空，LT模式返回读就绪。
  2. 对于写操作，只要缓冲区还不满，LT模式会返回写就绪。

当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。如果这次没有把数据一次性全部读写完(如读写缓冲区太小)，那么下次调用 epoll_wait()时，它还会通知你在上没读写完的文件描述符上继续读写，当然如果你一直不去读写，它会一直通知你。如果系统中有大量你不需要读写的就绪文件描述符，而它们每次都会返回，这样会大大降低处理程序检索自己关心的就绪文件描述符的效率。

2.边缘触发的时机

  1. 当缓冲区由不可读变为可读的时候，即缓冲区由空变为不空的时候。
  2. 当有新数据到达时，即缓冲区中的待读数据变多的时候。
  3. 当缓冲区有数据可读，且应用进程对相应的描述符进行EPOLL_CTL_MOD 修改EPOLLIN事件时。
  1. 当缓冲区由不可写变为可写时。
  2. 当有旧数据被发送走，即缓冲区中的内容变少的时候。
  3. 当缓冲区有空间可写，且应用进程对相应的描述符进行EPOLL_CTL_MOD 修改EPOLLOUT事件时。

当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。如果这次没有把数据全部读写完(如读写缓冲区太小)，那么下次调用epoll_wait()时，它不会通知你，也就是它只会通知你一次，直到该文件描述符上出现第二次可读写事件才会通知你。这种模式比水平触发效率高，系统不会充斥大量你不关心的就绪文件描述符。

在ET模式下， 缓冲区从不可读变成可读，会唤醒应用进程，缓冲区数据变少的情况，则不会再唤醒应用进程。

举例1：

  1. 读缓冲区刚开始是空的
  2. 读缓冲区写入2KB数据
  3. 水平触发和边缘触发模式此时都会发出可读信号
  4. 收到信号通知后，读取了1KB的数据，读缓冲区还剩余1KB数据
  5. 水平触发会再次进行通知，而边缘触发不会再进行通知

举例2：（以脉冲的高低电平为例）

JDK并没有实现边缘触发，Netty重新实现了epoll机制，采用边缘触发方式；另外像Nginx也采用边缘触发。

JDK在Linux已经默认使用epoll方式，但是JDK的epoll采用的是水平触发，而Netty重新实现了epoll机制，采用边缘触发方式，netty epoll transport 暴露了更多的nio没有的配置参数，如 TCP_CORK, SO_REUSEADDR等等；另外像Nginx也采用边缘触发。

epoll与select、poll的对比

1. 用户态将文件描述符传入内核的方式

2. 内核态检测文件描述符读写状态的方式

3. 找到就绪的文件描述符并传递给用户态的方式

4. 重复监听的处理方式

epoll更高效的原因

  1. select和poll的动作基本一致，只是poll采用链表来进行文件描述符的存储，而select采用fd标注位来存放，所以select会受到最大连接数的限制，而poll不会。
  2. select、poll、epoll虽然都会返回就绪的文件描述符数量。但是select和poll并不会明确指出是哪些文件描述符就绪，而epoll会。造成的区别就是，系统调用返回后，调用select和poll的程序需要遍历监听的整个文件描述符找到是谁处于就绪，而epoll则直接处理即可。
  3. select、poll都需要将有关文件描述符的数据结构拷贝进内核，最后再拷贝出来。而epoll创建的有关文件描述符的数据结构本身就存于内核态中，系统调用返回时利用mmap()文件映射内存加速与内核空间的消息传递：即epoll使用mmap减少复制开销。
  4. select、poll采用轮询的方式来检查文件描述符是否处于就绪态，而epoll采用回调机制。造成的结果就是，随着fd的增加，select和poll的效率会线性降低，而epoll不会受到太大影响，除非活跃的socket很多。
  5. epoll的边缘触发模式效率高，系统不会充斥大量不关心的就绪文件描述符

虽然epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。

更多内容，欢迎关注微信公众号：全菜工程师小辉~

声明：本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系，我们将立即删除或处理。
▍相关推荐
更多资讯 >>>
Copyright @ 简易百科 V 2.0 京ICP备14042104号