标签：epoll C++ 描述符 fd 内核 poll select
目录
摘要
先明确几个概念：
面试官问：给我讲讲什么事同步阻塞、异步阻塞、同步非阻塞、异步非阻塞。
我：？？？？？
同步和异步的概念
同步是指用户线程发起IO请求后,需要等待或者轮询内核IO操作完成后才能继续执行；
异步是指用户线程发起IO请求后仍继续执行，当内核IO操作完成后会通知用户线程或者调用用户线程注册的回调函数。
阻塞和非阻塞的概念
阻塞是指IO操作需要彻底完成后才返回到用户空间；
非阻塞是指IO操作被调用后立即返回给用户一个状态值，无需等到IO操作彻底完成。
I/O 同步和异步的区别在于：将数据从内核复制到用户空间时，用户进程是否会阻塞。
I/O 阻塞和非阻塞的区别在于：进程发起系统调用后，是会被挂起直到收到数据后在返回、还是立即返回成功或错误。
一般来讲一个IO分为两个阶段：
- 等待数据到达
- 把数据从内核空间拷贝到用户空间（数据的拷贝过程）
现在假设一个进程/线程A，试图进行一次IO操作。
A发出IO请求，两种情况：
- 立即返回
- 由于数据未准备好，需要等待，让出CPU给别的线程，自己睡眠挂起（sleep）
第一种情况就是非阻塞，A为了知道数据是否准备好，需要不停的询问，而在轮询的空歇期，理论上是可以干点别的活，例如喝喝茶、泡个妞。
第二种情况就是阻塞，A除了等待就不能做任何事情。
数据终于准备好了，A现在要把数据取回去，有几种做法：
- A自己把数据从内核空间拷贝到用户空间。
- A创建一个新线程（或者直接使用内核线程），这个新线程把数据从内核空间拷贝到用户空间。
第一种情况，所有的事情都是同一个线程做，叫做同步，有同步阻塞（BIO）、同步非阻塞（NIO）
第二种情况，叫做异步，只有异步非阻塞（AIO）
我：没有异步阻塞对不对（得意）
面试官：小伙子，不戳鸭～
文件描述符：系统为每一个进程维护了一个文件描述符表，表示该进程打开文件的记录表，而文件描述符实际上就是这张表的索引（下文代称fd）。
多路复用：为了实现一个服务器可以支持多个客户端连接。//主要服务器贵啊，不然一对一我也没意见:)
socket 创建连接过程，并把tcp/udp包含地址、类型和通信协议等信息对底层的封装进行屏蔽，返回一个连接或者fd。socket 通信，实际上就是通过文件描述符 fd 读写文件，这也符合 Unix“一切皆文件”的哲学。//学过linux的小伙伴肯定知道
select，poll，epoll都是IO多路复用的机制。I/O多路复用就通过一种机制，可以监视多个描述符fd，一旦某个描述符就绪(一般是读就绪或者写就绪)，系统会通知有I/O事件发生了（不能定位是哪一个）。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。
场景描述
生活时刻需要思考，最近我发现一个现象恰好贴切select、poll、epoll的场景描述。
高铁上，饭点时间到了。乘务员推着餐车出来从1号车厢走到8号车厢，一路上询问“啤酒饮料矿泉水,花生瓜子八宝粥～”。
select和poll的调用复杂度是线性的，即O(n)。
如果把fd描述符看成是顾客，那么进程就是乘务员，她会不断轮询整个列车车厢，去查看是否有有I/O读写操作。轮询一次效率是挺低的。
epoll版就不一样了，时间复杂度O(1)。
广播通知“顾客如果有购餐需要，可以扫码座位右手边二维码下单，餐车会将热好的饭菜自动送到您的桌前”。（科技发展就是好）不用轮询效率且非常高，而且理论上可以监听无数个顾客fd。只要fd有I/O事件通知给进程就可以了。
select、poll和epoll这三个函数是Linux系统中I/O复用的系统调用函数。I/O复用使得这三个函数可以同时监听多个文件描述符(File Descriptor, FD)，因为每个文件描述符相当于一个需要 I/O的“文件”，在socket中共用一个端口。
Select工作原理
什么时候才会有阻塞？
当你请求连接的时候，或者是进行接收到数据（等待服务器响应的时候）的时候都会发生阻塞。
什么是异步IO？
异步就是当你遇到IO操作的时候，也可以处理其他IO请求，select只能做到非阻塞而不能异步,异步IO基本就是多线程的并发处理可以实现。
select逻辑图：
Select可以是非阻塞模型，非阻塞并不一定是异步模型，但异步模型一定是非阻塞的。 Select模型如果要编写Windows界面程序必须使用多线程，否则就会把程序界面线程堵塞。
利用 select 函数来判断某Socket上是否有数据可读，或者能否向一个套接字写入数据，防止程序在Socket处于阻塞模式中时，在一次 I/O 调用（如send或recv、accept等）过程中，被迫进入“锁定”状态；
可以同时等待多个套接字，当某个或者多个套接字满足可读写条件时，通知应用程序调用输入或者输出函数进行读写。
同时防止在套接字处于非阻塞模式中时，产生WSAEWOULDBLOCK错误。它意味着请求的操作在调用期间没有时间完成。
select目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点。select的一个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定义甚至重新编译内核的方式提升这一限制，但是这样也会造成效率的降低。
select本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。这样所带来的缺点是：
- select最大的缺陷就是单个进程所打开的FD是有一定限制的，它由FD_SETSIZE设置，默认值是1024。
一般来说这个数目和系统内存关系很大，
具体数目可以cat /proc/sys/fs/file-max察看。32位机默认是1024个。64位机默认是2048.
- 对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低。
当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度，不管哪个Socket是活跃的，都遍历一遍。这会浪费很多CPU时间。
如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。
需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大。
select在内存中是一段连续的内存空间地址表示（类似于vector或者数组），它的事件的轮训机制是基于比特位的。每次查询都要遍历整个事件列表。
理解select，首先要理解select要处理的fd_set数据结构，每个select都要处理一个fd_set结构。fd_set简单地理解为一个长度是1024的比特位，每个比特位表示一个需要处理的FD，如果是1，那么表示这个FD有需要处理的I/O事件，否则没有。Linux为了简化位操作，定义了一组宏函数来处理这个比特位数组。
void FD_CLR(int fd, fd_set *set); // 清空fd在fd_set上的映射，说明select不在处理该fd
int FD_ISSET(int fd, fd_set *set); // 查询fd指示的fd_set是否是有事件请求
void FD_SET(int fd, fd_set *set); // 把fd指示的fd_set置1
void FD_ZERO(fd_set *set); // 清空整个fd_set，一般用于初始化从上述可以看出，select能处理fd最大的数量是1024，这是由fd_set的容量决定的。
fd_set 的二进制每一位来表示一个文件描述符。某一位为 1，表示对应的文件描述符已就绪。比如比如设 fd_set 长度为 1 字节，则一个 fd_set 变量最大可以表示 8 个文件描述符。当 select 返回 fd_set = 00010011 时，表示文件描述符 1、2、5 已经就绪，调用 select 时会陷入内核，这时需要将参数中的 fd_set 从用户空间拷贝到内核空间，内核需要遍历传递进来的所有 fd_set 的每一位(性能开销大)，不管它们是否就绪，同时能够监听的文件描述符数量太少(32位1024)。受限于 sizeof(fd_set) 的大小，在编译内核时就确定了且无法更改。一般是 1024，不同的操作系统不相同
poll
可以认为poll是一个增强版本的select，因为select的比特位操作决定了一次性最多处理的读或者写事件（文件描述符数量）只有1024个，而poll使用一个新的方式优化了这个模型。
还是先了解poll底层操作的数据结构pollfd：
struct pollfd {
int fd; // 需要监视的文件描述符
short events; // 需要内核监视的事件
short revents; // 实际发生的事件
};
在使用该结构的时候，不用进行比特位的操作，而是对事件本身进行操作就行。同时还可以自定义事件的类型。具体可以参考手册。这样的好处是在内存中存放就不需要连续的内存地址，很像是list队列结构，读或者写事件数量（文件描述符数量）理论上是无限的，取决于内存的大小。
poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。
总结：它没有最大连接数的限制，原因是它是基于链表来存储的，但是同样有缺点：
- 内核需要将消息传递到用户空间，都需要内核拷贝动作。需要维护一个用来存放大量fd的数据结构，使得用户空间和内核空间在传递该结构时复制开销大。大量的fd被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。
- poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。
epoll
由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。
epoll给出了一个新的模式，直接申请一个epollfd的文件，对这些进行统一的管理，初步具有了面向对象的思维模式。可理解为event poll，epoll会把哪个流发生哪种I/O事件通知我们。所以epoll是事件驱动（每个事件关联fd）的，此时我们对这些流的操作都是有意义的。复杂度也降低到了O(1)。
epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。把原先的select/poll调用分成了3个部分：
- 调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
- 调用epoll_ctl向epoll对象中添加这些连接的套接字
- 调用epoll_wait收集发生的事件的连接
如此一来只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这些连接的句柄数据，内核也不需要去遍历全部的连接。
当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体如下所示：
struct eventpoll{
....
/*红黑树的根节点，这颗树中存储着所有添加到epoll中的需要监控的事件*/
struct rb_root rbr;
/*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/
struct list_head rdlist;
....
};
每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，如此，重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的元素数量)。
而所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。
在epoll中，对于每一个事件，都会建立一个epitem结构体，如下所示：
struct epitem{
struct rb_node rbn;//红黑树节点
struct list_head rdllink;//双向链表节点
struct epoll_filefd ffd; //事件句柄信息
struct eventpoll *ep; //指向其所属的eventpoll对象
struct epoll_event event; //期待发生的事件类型
}
当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。
epoll通过内核和用户空间共享一块内存来实现消息传递，epoll_create 会创建一个 epoll 实例，同时返回一个引用该实例的fd（文件描述符）。所以在使用完 epoll 后，必须调用 close() 关闭对应的文件描述符。epoll_ctl 绑定fd指向epoll实例，就是要监听的fd和event，将文件描述符 fd 添加到 epoll 实例的监听列表（红黑树），同时为 fd 设置一个回调函数，并监听事件 event。当 fd 上发生相应事件时，会调用回调函数，将 fd 添加到 epoll 实例的就绪队列（rdlist双链表）上。epoll_wait就相当于select，epoll_ctl 中为每个文件描述符指定了回调函数，并在就绪时将其加入到就绪队列（rdlist双链表），因此 epoll 不需要像 select 那样遍历检测每个文件描述符，只需要判断就绪列表（rdlist双链表）是否为空即可。这样，在没有描述符就绪时，epoll 能更早地让出系统资源。
从上面的讲解可知：通过红黑树和双链表数据结构，并结合回调机制，造就了epoll的高效。
OK，讲解完了Epoll的机理，我们便能很容易掌握epoll的用法了。一句话描述就是：三步曲。
第一步：epoll_create()系统调用。此调用返回一个句柄，之后所有的使用都依靠这个句柄来标识。
第二步：epoll_ctl()系统调用。通过此调用向epoll对象中添加、删除、修改感兴趣的事件，返回0标识成功，返回-1表示失败。
第三部：epoll_wait()系统调用。通过此调用收集收集在epoll监控中已经发生的事件。
EPOLLLT和EPOLLET两种：
- LT，默认的模式（水平触发） 只要该fd还有数据可读，每次
epoll_wait都会返回它的事件，提醒用户程序去操作， - ET是“高速”模式（边缘触发）
只会提示一次，直到下次再有数据流入之前都不会再提示，无论fd中是否还有数据可读。所以在ET模式下，read一个fd的时候一定要把它的buffer读完，即读到read返回值小于请求值或遇到EAGAIN错误
epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似回调机制激活该fd，epoll_wait便可收到通知。
EPOLLET触发模式的意义
若用EPOLLLT，系统中一旦有大量无需读写的就绪文件描述符，它们每次调用epoll_wait都会返回，这大大降低处理程序检索自己关心的就绪文件描述符的效率。 而采用EPOLLET，当被监控的文件描述符上有可读写事件发生时，epoll_wait会通知处理程序去读写。如果这次没有把数据全部读写完(如读写缓冲区太小)，那么下次调用epoll_wait时，它不会通知你，即只会通知你一次，直到该文件描述符上出现第二次可读写事件才会通知你。这比水平触发效率高，系统不会充斥大量你不关心的就绪文件描述符。
总结
select、poll、epoll 区别总结：
1、支持一个进程所能打开的最大连接数
select：单个进程所能打开的最大连接数有FD_SETSIZE宏定义，其大小是32个整数的大小（在32位的机器上，大小就是3232，同理64位机器上FD_SETSIZE为3264），当然我们可以对进行修改，然后重新编译内核，但是性能可能会受到影响，这需要进一步的测试。
poll：poll本质上和select没有区别，但是它没有最大连接数的限制，原因是它是基于链表来存储的。
epoll：虽然连接数有上限，但是很大，1G内存的机器上可以打开10万左右的连接，2G内存的机器可以打开20万左右的连接。
2、fd剧增后带来的IO效率问题
select：因为每次调用时都会对连接进行线性遍历，所以随着FD的增加会造成遍历速度慢的“线性下降性能问题”。
poll：同上
epoll：因为epoll内核中实现是根据每个fd上的callback函数来实现的，只有活跃的socket才会主动调用callback，所以在活跃socket较少的情况下，使用epoll没有前面两者的线性下降的性能问题，但是所有socket都很活跃的情况下，可能会有性能问题。
3、 消息传递方式
select：内核需要将消息传递到用户空间，都需要内核拷贝动作
poll：同上
epoll：epoll通过内核和用户空间共享一块内存来实现的。
总结：
综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特点。
表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。
select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。
select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善
select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。
标签：epoll,C++,描述符,fd,内核,poll,select 来源： https://blog.csdn.net/u014430031/article/details/115430161
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。