muduo 05 select、poll、epoll总结_muduo水平触发-优快云博客

本文链接：https://blog.youkuaiyun.com/super8ayan/article/details/131403182

文章讨论了select和poll的缺点，如文件描述符数量限制、内存拷贝开销以及轮询效率低。接着介绍了epoll的优势，包括通过内核共享内存避免复制、支持大量并发连接以及高效的回调机制。epoll使用红黑树管理文件描述符，当事件发生时，将就绪的描述符添加到双向链表中，通过epoll_wait返回。文章还提到了epoll的两种触发模式：水平触发和边缘触发，以及它们的适用场景。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

select和poll的缺点

epoll原理及优势

epoll底层的红黑树和双向链表各自什么时候使用

select：将文件描述符放入一个集合中，调用select时，将这个集合从用户空间拷贝到内核空间（缺点1：每次都要复制，开销大），由内核根据就绪状态修改该集合的内容。（缺点2）集合大小有限制，32位机默认是1024（64位：2048）；采用水平触发机制。select函数返回后，需要通过遍历这个集合，找到就绪的文件描述符（缺点3：轮询的方式效率较低），当文件描述符的数量增加时，效率会线性下降；
poll：和select几乎没有区别，区别在于文件描述符的存储方式不同，poll采用链表的方式存储，没有最大存储数量的限制；
epoll：通过内核和用户空间共享内存，避免了不断复制的问题；支持的同时连接数上限很高（1G左右的内存支持10W左右的连接数）；文件描述符就绪时，采用回调机制，避免了轮询（回调函数将就绪的描述符添加到一个链表中，执行epoll_wait时，返回这个链表）；支持水平触发和边缘触发，采用边缘触发机制时，只有活跃的描述符才会触发回调函数。

select和poll的缺点

单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但是由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差。
内核/用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大开销。
select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现那些句柄发生了事件。
select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。

poll和select相比，因为poll使用链表保存文件描述符，因此没有了监视文件数量的限制，其他三个缺点依然存在。

epoll原理及优势

epoll的实现机制与select/poll机制完全不同，它们的缺点在epoll上不复存在。

设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？

在select/poll时代，服务器进程每次都把这个100万个连接告诉操作系统（从用户态拷贝到内核态）让操作系统内核去轮询判断事件的发生，轮询完成后，再将句柄数据复制到用户态，让服务器应用程序轮询已经发生的网络事件，这一过程资源消耗太大，因此select/poll一般只能处理几千的并发连接。

epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统（文件系统一般用什么数据结构实现？红黑树树，磁盘IO消耗低，效率很高）。把原先的select/poll调用分成以下3个部分：

1）用户态调用epoll_create()在内核中建立一个epoll对象（在epoll文件系统中为这个句柄对象分配资源）并返回一个文件描述符，该文件描述符用于后续对该 epoll 对象进行操作。

2）调用epoll_ctl向epoll对象中添加这100万个连接的套接字，红黑树

3）调用epoll_wait收集发生的事件的fd资源（从红黑树节点中摘录出发生事件的节点，放到双向链表中《返回一个发生事件集合》）

如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除事件。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。

epoll底层的红黑树和双向链表各自什么时候使用

1.红黑树

epoll使用红黑树来管理和存储注册的文件描述符（file descriptors，简称 fd）
当你调用 epoll_ctl 来添加、删除或修改监听的文件描述符时，这些描述符会在红黑树中进行相应的操作。
红黑树是一个自平衡的二叉查找树，所以 epoll 可以在 O(log n) 的时间内插入、删除和查找文件描述符。
这意味着，红黑树主要用于文件描述符的管理和查找。

2.双向链表

当某个文件描述符上发生了一个事件（如可读、可写等），这个描述符会被加入到一个双向链表中。
当你调用 epoll_wait 函数时，它会检查这个双向链表来返回那些已经准备好的文件描述符。
由于事件的处理顺序可能和事件的发生顺序不一样，使用双向链表能够快速地插入和删除元素。
因此，双向链表主要用于事件的通知和分发。

epoll三大核心接口：

epoll_create:

epoll_create在内核上创建的event poll结构如下：

struct eventpoll{
....
/*红黑树的根节点，这颗树中存储着所有添加到epoll中的需要监控的事件*/
struct rb_root rbr;
/*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/
struct list_head rdlist;
....
};

epoll_ctl:

epoll_event结构体的成员如下：

events：是一个无符号32位整数，表示事件类型的位掩码。常用的事件类型包括：

EPOLLIN：表示可读事件。

EPOLLOUT：表示可写事件。

EPOLLERR：表示错误事件。

EPOLLPRI：表示高优先级可读事件。

EPOLLHUP：表示挂起事件（连接断开或关闭）。

EPOLLET：设置为边缘触发模式（Edge Triggered）。

EPOLLONESHOT：设置为一次性事件（One-Shot），即只监听一次事件，之后需要重新添加。

data：是一个epoll_data_t联合体类型的变量，用于与事件相关的数据。epoll_data_t可以存储不同类型的数据，根据具体的使用情况选择合适的成员：

ptr：一个void*类型的指针，可以存储指向事件相关数据的指针。

fd：一个整数，表示事件关联的文件描述符。

将哪个客户端(fd)的哪些事件(event)交给哪个epoll(epfd)来管理(op:增删改)

epoll_wait:

水平触发LT

只要一个文件描述符就绪，就会触发通知，如果用户程序没有一次性把数据读写完，下次还会通知。

边缘触发一定要用非阻塞IO：避免由于一个描述符的阻塞读/写操作让其他描述符的任务出现饥饿状态，比如说我用一个阻塞操作去读取一个空的文件，他就会一直阻塞在那里，无法操作其他的文件描述符的任务。

边缘触发ET

当描述符从未就绪变为就绪时通知一次，之后不会再通知，直到再次从未就绪变为就绪（缓冲区从不可读/写变为可读/写）

边缘触发效率更高，减少了被重复触发的次数，函数不会返回大量用户程序可能不需要的文件描述符。

然而，ET模式也存在一些注意事项：

需要确保使用非阻塞IO方式进行读写操作，否则可能导致数据处理不完整。
必须将已就绪的事件处理完毕，否则可能导致事件丢失。
对于某些情况下需要实时处理数据的场景，LT模式可能更合适，因为它会持续通知文件描述符上的可读或可写状态。

（不能保证每个就绪事件都能得到触发，可能导致事件丢失，不能及时得到处理）

并不是epoll的ET模式就是一定好的，在极端的情况下，一个套接字上的数据远远不断的过来，因为ET模式，这个socket上的数据从不可读到可读，不可写到可写只会通知一次，之后应用程序会不断的去循环从这个socket上去读取数据，其他就绪的套接字可能会得不到处理。

muduo库采用的是LT模式：

容易理解和使用：相对于ET模式，LT模式更容易理解和使用。在LT模式下，当套接字有数据可读或可写时，每次epoll_wait都会返回该就绪事件，应用程序只需要在处理完当前就绪事件后继续等待下一次事件即可。这样简化了应用程序的处理逻辑和编程复杂性。

兼容性好可跨平台：LT模式是兼容性较好的模式，在不同的操作系统和平台上都能正常工作。相比之下，ET模式在不同的操作系统上可能存在一些细微的差异和实现限制。

避免饥饿问题：在LT模式下，如果一个套接字一直有数据到来，epoll_wait会持续通知应用程序有可读事件，保证了公平性，其他套接字也能得到处理。而在ET模式下，如果一个套接字一直保持就绪状态，可能会导致其他套接字得不到处理，出现饥饿的情况。不会因为某个连接上的数据量过大而影响其他连接处理消息。

不会丢失数据或消息，容错性更好：在LT模式下，即使应用程序没有立即处理就绪事件，下一次epoll_wait仍然会返回相同的就绪事件，确保不会错过事件通知。这样在应用程序的处理逻辑出现延迟时，仍然能够正常处理就绪事件。