epoll详解？

一、epoll详解？

按照man手册的说法：是为处理大批量句柄而作了改进的poll。当然，这不是2.6内核才有的，它是在2.5.44内核中被引进的(epoll(4) is a new API introduced in Linux kernel 2.5.44)，它几乎具备了之前所说的一切优点，被公认为Linux2.6下性能最好的多路I/O就绪通知方法。

二、epoll原理？

epoll是一种IO多路转接技术，在LINUX网络编程中，经常用来做事件触发，即当有特定事件到来时，能够检测到，而不必阻塞进行监听。

　　epoll有两种工作方式，ET-水平触发 和 LT-边缘触发（默认工作方式），主要的区别是：

　　LT，内核通知你fd是否就绪，如果没有处理，则会持续通知。而ET，内核只通知一次

三、epoll底层原理？

epoll的实现原理

epoll_create

在epoll文件系统建立了个file节点，并开辟epoll自己的内核高速cache区，建立红黑树，分配

好想要的size的内存对象，建立一个list链表，用于存储准备就绪的事件。

epoll_ctl

把要监听的socket放到对应的红黑树上，给内核中断处理程序注册一个回调函数，通知内核，如果

这个句柄的数据到了，就把它放到就绪列表。

epoll_wait

观察就绪列表里面有没有数据，并进行提取和清空就绪列表，非常高效。

四、epoll的特点？

支持一个进程打开的socket描述符（fd）不受限制（仅受限于操作系统的最大文件句柄数）

select最大的缺陷单个进程锁打开的fd是由一定限制的，由FD_SETSIZE设置（默认1024），想要修改需要重新编译内核。Java由于没有共享内存，需要通过socket或其他方式进行数据同步，有额外性能开销。epoll没有这个限制，可支持的fd位操作系统最大文件句柄数，1G内存大约10万个句柄。

I/O效率不会随着fd数目增加而线性下降

select每次都会现行扫描全部集合，在网络延时或链路空闲时，效率会比较低。epoll首先会向每个fd上注册事件，当fd状态就绪时，会调用callback，不需要遍历所有的fd。只有在所有的socket都处于活跃状态，epoll才会没有优势，甚至效率低于select

五、epoll模型的原理？

原理就是

创建epoll模型,其实就是打开一个文件,epoll_create返回一个文件描述符。此时会创建一棵红黑树和就绪队列。

六、epoll和reactor区别？

epoll是Linux内核为处理大批量文件描述符而作了改进的poll，是Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。

而Reactor是第四代响应式库，是一个响应式编程范式的实现，用于在JVM平台上基于响应式流规范构建非阻塞异步应用。它是一个完全非阻塞响应式编程的基石。

七、redis epoll模型详解？

Redis 是一款高性能的内存数据库，它采用了 epoll 模型来实现高效的 IO 处理。

首先，Redis 使用的是单线程架构，所以 IO 处理对性能影响较大。而 epoll 模型能够最大限度地利用操作系统提供的异步 IO 支持实现高效 IO 处理。

epoll 模型的基本流程如下：

1. 创建 epoll 实例。

2. 对 epoll 实例进行管理的文件描述符进行注册：使用 epoll_ctl 函数将文件描述符添加到 epoll 实例的事件集合中，并为其关联事件类型和事件回调函数。

3. 等待状态变化：使用 epoll_wait 函数等待注册的文件描述符的指定事件（如读就绪、写就绪、异常等）发生，从而得到事件。

4. 处理就绪事件：根据得到的事件类型和事件回调函数，进行相应的处理。

在 Redis 中，epoll 模型主要用于网络 IO 处理，将客户端连接和服务端 socket 注册到 epoll 实例的事件集合中，然后通过 epoll_wait 函数等待可读事件发生，处理读事件时将数据读取并存储到内存中，处理写事件时将数据从内存中写回客户端连接。这样可以实现非阻塞 IO 处理，提高 Redis 数据库的性能。

八、epoll和select的区别？

select的句柄数目受限。而epoll没有，它的限制是最大的打开文件句柄数目。

epoll是不会随着FD的数目增长而降低效率，在selec中采用轮询处理，其中的数据结构类似一个数组的数据结构，而epoll是维护一个队列，直接看队列是不是空就可以了。

epoll使用mmap加速内核与用户空间的消息传递。 扩展资料

　　问题的引出，当需要读两个以上的I/O的时候，如果使用阻塞式的I/O，那么可能长时间的阻塞在一个描述符上面，另外的.描述符虽然有数据但是不能读出来，这样实时性不能满足要求，大概的解决方案有以下几种：

　　1.使用多进程或者多线程，但是这种方法会造成程序的复杂，而且对与进程与线程的创建维护也需要很多的开销。（Apache服务器是用的子进程的方式，优点可以隔离用户）

　　2.用一个进程，但是使用非阻塞的I/O读取数据，当一个I/O不可读的时候立刻返回，检查下一个是否可读，这种形式的循环为轮询（polling），这种方法比较浪费CPU时间，因为大多数时间是不可读，但是仍花费时间不断反复执行read系统调用。

　　3.异步I/O（asynchronous I/O），当一个描述符准备好的时候用一个信号告诉进程，但是由于信号个数有限，多个描述符时不适用。

　　4.一种较好的方式为I/O多路转接（I/O multiplexing）（貌似也翻译多路复用），先构造一张有关描述符的列表（epoll中为队列），然后调用一个函数，直到这些描述符中的一个准备好时才返回，返回时告诉进程哪些I/O就绪。select和epoll这两个机制都是多路I/O机制的解决方案，select为POSIX标准中的，而epoll为Linux所特有的。

九、epoll和select区别总结？

epoll是Linux内核为处理大批量文件描述符而作了改进的poll，是Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。

elect是一个计算机函数，位于头文件#include 。该函数用于监视文件描述符的变化情况——读写或是异常。

十、poll和epoll的区别？

epoll是对select和poll的改进，就应该能避免上述的三个缺点。那epoll都是怎么解决的呢？在此之前，我们先看一下epoll和select和poll的调用接口上的不同，select和poll都只提供了一个函数——select或者poll函数。而epoll提供了三个函数，epoll_create,epoll_ctl和epoll_wait，epoll_create是创建一个epoll句柄；epoll_ctl是注册要监听的事件类型；epoll_wait则是等待事件的产生。

　　对于第一个缺点，epoll的解决方案在epoll_ctl函数中。每次注册新的事件到epoll句柄中时（在epoll_ctl中指定EPOLL_CTL_ADD），会把所有的fd拷贝进内核，而不是在epoll_wait的时候重复拷贝。epoll保证了每个fd在整个过程中只会拷贝一次。

　　对于第二个缺点，epoll的解决方案不像select或poll一样每次都把current轮流加入fd对应的设备等待队列中，而只在epoll_ctl时把current挂一遍（这一遍必不可少）并为每个fd指定一个回调函数，当设备就绪，唤醒等待队列上的等待者时，就会调用这个回调函数，而这个回调函数会把就绪的fd加入一个就绪链表）。epoll_wait的工作实际上就是在这个就绪链表中查看有没有就绪的fd（利用schedule_timeout()实现睡一会，判断一会的效果，和select实现中的第7步是类似的）。

　　对于第三个缺点，epoll没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。