linux下epoll模型accept并发问题 ---ET下

最新推荐文章于 2024-10-12 22:54:45 发布
最新推荐文章于 2024-10-12 22:54:45 发布
阅读量574 收藏
点赞数
分类专栏： epoll
文章详细介绍了在使用epoll网络模型处理多用户并发通信时遇到的异常问题，以及如何通过调整epoll工作模式和循环处理接受连接的方法来解决此问题，确保客户端和服务端能够正常通信。
沧龙

最近用c++实现了贝叶斯分类算法，做了个自动识别垃圾信息的小工具。工具中有个功能，通过绑定指定端口，和客户端通信。服务端使用的是epoll网络模型。在测试的时候发现，单用户的情况下客户端和服务器通信正常。但是在多用户并发的情况下，客户端和服务端通信不正常。此时，客户端能正常的链接，发送数据，但是一直卡在接收数据部分。如下图：

出现这种问题，是因为不正确的使用了epoll中的ET（edge-trigger）模式。代码如下：

01/**************************************************
02函数名：acceptConn
03功能：接受客户端的链接
04参数：srvfd：监听SOCKET
05***************************************************/
06void acceptConn(int srvfd)
07{
08struct sockaddr_in sin;
09socklen_t len = sizeof(struct sockaddr_in);
10bzero(&sin, len);
11 
12int confd = accept(srvfd, (struct sockaddr*)&sin, &len);
13 
14if (confd < 0)
15{
16printf("%s: bad accept\n");
17return;
18}else
19{
20printf("Accept Connection: %d", confd);
21}
22 
23setNonblocking(confd);
24 
25//将新建立的连接添加到EPOLL的监听中
26struct epoll_event event;
27event.data.fd = confd;
28event.events =�0�2 EPOLLIN|EPOLLET;
29epoll_ctl(epollfd, EPOLL_CTL_ADD, confd, &event);
30}

注意倒数第二行：event.events = EPOLLIN|EPOLLET; 采用的是ET模式。下面我们来具体说下，问题出在那里。

在epoll中有两种模式：level-trigger模式，简称LT模式，和edge-trigger模式，简称ET模式。其中，LT是默认的工作模式。

这两种模式的工作方式有些不同。在level-trigger模式下只要某个socket处于readable/writable状态，无论什么时候进行epoll_wait都会返回该socket；而edge-trigger模式下只有某个socket从unreadable变为readable或从unwritable变为writable时，epoll_wait才会返回该socket。

在ET模式socket非阻塞的情况下（上面代码中就是这种情况），多个连接同时到达，服务器的TCP就绪队列瞬间积累多个就绪连接，由于是边缘触发模式，epoll只会通知一次，accept只处理一个连接，导致TCP就绪队列中剩下的连接都得不到处理。因此，就出现了上面所提及的问题。

解决办法是用while循环抱住accept调用，处理完TCP就绪队列中的所有连接后再退出循环。如何知道是否处理完就绪队列中的所有连接呢？accept返回-1并且errno设置为EAGAIN就表示所有连接都处理完。

修改后的代码如下：

01/**************************************************
02函数名：acceptConn
03功能：接受客户端的链接
04参数：srvfd：监听SOCKET
05***************************************************/
06void acceptConn(int srvfd)
07{
08struct sockaddr_in sin;
09socklen_t len = sizeof(struct sockaddr_in);
10bzero(&sin, len);
11int confd = 0;
12while((confd = accept(srvfd, (struct sockaddr*)&sin, &len)) > 0) {
13
14printf("Accept Connection: %d", confd);
15 
16setNonblocking(confd);
17 
18//将新建立的连接添加到EPOLL的监听中
19struct epoll_event event;
20event.data.fd = confd;
21event.events =�0�2 EPOLLIN|EPOLLET;
22epoll_ctl(epollfd, EPOLL_CTL_ADD, confd, &event);
23}
24if (confd == -1) {
25if (errno != EAGAIN && errno != ECONNABORTED && errno != EPROTO && errno != EINTR){
26printf("%s: bad accept\n");
27return;
28}
29}
30}
同理，接收数据和发送数据时如果是ET模式，且非阻塞，也得用循环。
读：只要可读，就一直读，直到返回0，或者 errno = EAGAIN
写:只要可写，就一直写，直到数据发送完，或者 errno = EAGAIN
正确的读：
1n = 0;
2while ((nread = read(fd, buf + n, BUFSIZ-1)) > 0) {
3n += nread;
4}
5if (nread == -1 && errno != EAGAIN) {
6perror("read error");
7}

正确的写：

01int nwrite, data_size = strlen(buf);
02n = data_size;
03while (n > 0) {
04nwrite = write(fd, buf + data_size - n, n);
05if (nwrite < n) {
06if (nwrite == -1 && errno != EAGAIN) {
07perror("write error");
08}
09break;
10}
11n -= nwrite;
12
由一个EPOLLET模式accept()问题引起对TCP连接的回顾
kapuchang的博客
01-20 998
问题起因 在生产环境出现一个TCP网络连接的异常，socket accept()时返回错误，错误码errno=24，strerror=”Too many open files”，线程占用CPU接近100%，即死循环。查明直接原因是，进程的open files数量太小，当连接数超时该数目时即会返回上述错误。（这要提醒一句：要注意父子进程的limits参数，也许系统配置参数已修改，但父进程是在修改前启...
Linux--多路转接之epoll
m0_74068921的博客
10-15 2064
正是因为底层的红黑树会先存储着对应的事件信息，当被监测的文件描述符上有事件发生时，将相应的epitem插入到eventpoll的就绪链表（rdllist）中。: 虽然在底层有红黑树来进行存储对应的事件，但是在用户层是无法了解到底层的存储执行的，因为epoll的底层全由系统来完成的，用户无法操作，所以还需要一个事件数组来存储对应的事件。: epoll是Linux底层中一种高效的I/O多路复用机制，所以也是属于一种事件，需要在用户层创建对应的文件描述符用于表示对epoll的创建；
epoll的ET和LT模式下，accept，recv，send写法
09-01 266
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接：https://blog.csdn.net/peng314899581/article/details/78066374 epoll的ET和LT模式触发场景 accept的写法...
linux下epoll模型并发问题
weixin_34166847的博客
07-17 212
最近用c++实现了贝叶斯分类算法，做了个自动识别垃圾信息的小工具。工具中有个功能，通过绑定指定端口，和客户端通信。服务端使用的是epoll网络模型。在测试的时候发现，单用户的情况下客户端和服务器通信正常。但是在多用户并发的情况下，客户端和服务端通信不正常。此时，客户端能正常的链接，发送数据，但是一直卡在接收数据部分。如下图：出现这种问题，是因为不正确的使用了epoll中的E...
Linux下服务器端使用EPOLL ACCEPT产生的问题
伍意的博客
01-30 832
最近查了3天一个技术BUT，开始并不知道是网络问题，一步步定位，最终确定是网络接收问题。 进而深入前人的代码才有所察觉，因这个问题是随机性，很难重现。找到了网络问题，立马写代码重现。果然立马重现了。确定是EPOLL accept问题。 因为我们的问题是服务器端 接收缓冲区中一直有数据，拿不走，连接是已建立。 看看我们的代码 问题出在EPOLL的模式上，EPOLL有水平模式
nginx中epoll模块
liutengteng0929的博客
05-28 1141
一、epoll模块的介绍在nginx中，epoll模块是事件模块中的一个重要的模块，这个模块主要是对网络io进行操作，默认边沿触发     一般来说，nginx模块会有与配置部分相关的commands的数组，来配置解析配置文件中相关的配置信息部分，在nginx中在全局部分有如下的配置：在events模块中配置epoll时间数组的个数，也可以使用默认值static ngx_command_t  ng...
[Linux网络编程]高并发-Epoll模型
weixin_44972997的博客
10-04 2996
Epoll模型的三个函数 函数原型+功能说明 (1)epoll_create()参数使用 (2)epoll_ctl()参数使用 (3)epoll_wait()参数使用 Epoll和Select区别对比 Epoll模型封装成类 Epoll简单实现打印 代码+解释
Linux epoll模型
2401_86940371的博客
10-12 874
该程序一个简单的聊天室程序，用Linux C++写的，服务器主要是用epoll模型实现，支持高并发，我测试在有10000个客户端连接服务器的时候，server处理时间不到1秒，当然客户端只是与服务器连接之后，接受服务器的欢迎消息而已，并没有做其他的通信。LT(level triggered)：水平触发，缺省方式，同时支持block和no-block socket，在这种做法中，内核告诉我们一个文件描述符是否被就绪了，如果就绪了，你就可以对这个就绪的fd进行IO操作。程序共包含2个头文件和3个cpp文件。
linux网络编程：深入理解epoll模型
2401_86353562的博客
07-17 1089
有的朋友可能对select也不是很了解啊，我这里稍微科普一下：网络连接，服务器也是通过文件描述符来管理这些连接上来的客户端，既然是供连接的服务器，那就免不了要接收来自客户端的消息。那么多台客户端，消息那么的多，要是漏了一条两条重要消息，那也不要用TCP了，那怎么办？前辈们就是有办法，轮询，轮询每个客户端文件描述符，查看他们是否带着消息，如果带着，那就处理一下；如果没带着，那就一边等着去。这就是select，轮询，颇有点领导下基层的那种感觉哈。
linux-xia-epoll-socket.rar_epoll_epoll socket_socket_windows soc
09-22
综上所述，这个压缩包可能包含的代码示例或教程将详细展示如何在Linux下利用`epoll`和`socket`构建一个高性能的网络服务器，处理多用户的并发请求。通过学习这部分内容，开发者可以提升在高并发环境下的编程能力，...
高性能网络编程（一）accept建立连接
woaiwojialanxi的专栏
03-23 631
编写服务器时，许多程序员习惯于使用高层次的组件、中间件（例如OO（面向对象）层层封装过的开源组件），相比于服务器的运行效率而言，他们更关注程序开发的效率，追求更快的完成项目功能点、希望应用代码完全不关心通讯细节。他们更喜欢在OO世界里，去实现某个接口、实现这个组件预定义的各种模式、设置组件参数来达到目的。学习复杂的通讯框架、底层细节，在习惯于使用OO语言的程序员眼里是绝对事倍功半的。以上做法无可厚非，但有一定的局限性，本文讲述的网络编程头前冠以“高性能”，它是指程序员设计编写的服务器需要处理很大的吞吐量，这
epoll中accept的使用细节
鸟欲高飞先振翅，人求上进先读书
09-06 2396
accept 要考虑 2 个问题 (1) 阻塞模式 accept 存在的问题 考虑这种情况：TCP连接被客户端夭折，即在服务器调用accept之前，客户端主动发送RST终止连接，导致刚刚建立的连接从就绪队列中移出，如果套接口被设置成阻塞模式，服务器就会一直阻塞在accept调用上， 直到其他某个客户建立一个新的连接为止。但是在此期间，服务器单纯地阻塞在accept调用上，就绪队列中的其他描述符
epoll简介及触发模式（accept、read、send）
闪电小子
11-07 1486
简介： 　　1、epoll的简单介绍 　　 2、epoll在LT和ET模式下的读写方式 一、epoll的接口非常简单，一共就三个函数：1. int epoll_create(int size); 创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大。这个参数不同于select()中的第一个参数，给出最大监听的fd+1的值。需要注意的是，当创建好epoll句柄后，它就是...
linux 多线程或多进程 epoll处理 accept 惊群问题
Linux高级开发的博客
02-21 3182
什么是惊群 简单说，惊群是因为多进程（多线程）在同时阻塞等待同一个事件的时候（休眠状态），当时间发生时，就会唤醒所有等待的（休眠的）进程（线程）。但是事件只能被一个进程或线程处理，而其他进程（线程）获取失败，只能重新进入休眠状态，这种现象和性能浪费就叫做惊群。 产生惊群的条件 多个进程或者多个线程 同时等待处理一个事件 具体场景复现 测试环境 : debian11 内核5.10.0-8 编译器 clang11 多线程和多进程在惊群问题上差不多，为了少些一点，下文中没有特殊说明，多线程 也包含
彻底学会使用epoll(五)—— ET模式下的注意事项
lishenglong666的专栏
05-06 980
5.1 ET模式下的读写     经过前面几节分析，我们可以知道，当epoll工作在ET模式下时，对于读操作，如果read一次没有读尽buffer中的数据，那么下次将得不到读就绪的通知，造成buffer中已有的数据无机会读出，除非有新的数据再次到达。对于写操作，主要是因为ET模式下fd通常为非阻塞造成的一个问题——如何保证将用户要求写的数据写完。 要解决上述两个ET模式下的读写问题，我
UNIX网络编程——epoll 的accept , read, write(重要)
weixin_34008784的博客
08-02 406
在一个非阻塞的socket上调用read/write函数，返回EAGAIN或者EWOULDBLOCK(注：EAGAIN就是EWOULDBLOCK)。 从字面上看，意思是：EAGAIN： 再试一次EWOULDBLOCK：如果这是一个阻塞socket， 操作将被blockperror输出：Resource temporarily unavailable总结： ...
网络编程：epoll、accept触发模式及阻塞方式的选择
夜夜夜夜
12-27 8012
select(),poll()模型都是水平触发模式，信号驱动IO是边缘触发模式，epoll()模型即支持水平触发，也支持边缘触发，默认是水平触发 从表象看epoll的性能最好，但是在连接数少，并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多回调函数来完成。epoll工作在两种触发模式下： Level_triggered(水平触发)：当
自己趟过epoll的坑
热门推荐
linuxheik的专栏
06-15 1万+
坑的背景 本人用epoll来实现多路复用，epoll触发模式有两种： ET（边缘模式）LT（水平模式） LT模式 是标准模式，意味着每次epoll_wait()返回后，事件处理后，如果之后还有数据，会不断触发，也就是说，一个套接字上一次完整的数据，epoll_wait()可能会返回多次，直到没有数据为止。 ET模式 也称高效模式，有数据过来后，epoll_wait()会
linux epoll模型
最新发布
08-09
<think>我们正在讨论Linux的epoll模型。根据引用[1]和引用[2]，epoll是Linux内核提供的高性能I/O事件通知机制，用于解决select/poll在处理大量并发连接时的性能问题。下面我将详细解释epoll的工作原理和使用方法。 ### 一、epoll的工作原理 epoll的核心设计在于高效地管理大量文件描述符（fd），其核心数据结构包括： 1. **红黑树（Red-Black Tree）**：用于存储所有需要监听的fd，实现高效的插入、删除和查找操作（时间复杂度为$O(\log n)$）。 2. **就绪链表（Ready List）**：当某个fd上有事件发生时，内核会将该fd加入一个就绪链表，这样无需遍历整个fd集合。 #### 工作流程 1. **创建epoll实例**：`epoll_create()`创建一个epoll对象，并返回其文件描述符（epfd）。 2. **管理监听fd**：`epoll_ctl()`向epoll实例中添加、修改或删除需要监听的fd及其事件类型（如可读、可写）。 3. **等待事件就绪**：`epoll_wait()`阻塞等待，直到有事件发生。当有事件发生时，内核会将就绪的fd及其事件复制到用户空间，避免了遍历所有fd的开销。 ### 二、epoll的触发模式 epoll支持两种事件触发模式： 1. **水平触发（LT，Level-Triggered）**（默认模式）： - 只要fd处于就绪状态（如读缓冲区非空），就会持续通知。 - 优点：编程简单，不易遗漏事件。 - 缺点：可能重复通知，增加CPU开销。 2. **边缘触发（ET，Edge-Triggered）**： - 仅在fd状态变化时通知一次（如从不可读变为可读）。 - 优点：减少重复通知，提高效率。 - 缺点：必须一次性处理完所有数据，否则可能丢失事件（需搭配非阻塞I/O循环读取）。 ### 三、epoll的使用方法 #### 基本步骤 ```c #include <sys/epoll.h> // 1. 创建epoll实例 int epfd = epoll_create1(0); // 参数flags通常为0 // 2. 添加监听fd（示例：监听标准输入） struct epoll_event ev; ev.events = EPOLLIN; // 监听可读事件 ev.data.fd = STDIN_FILENO; epoll_ctl(epfd, EPOLL_CTL_ADD, STDIN_FILENO, &ev); // 3. 等待事件 struct epoll_event events[MAX_EVENTS]; while (1) { int nfds = epoll_wait(epfd, events, MAX_EVENTS, -1); // 阻塞等待 for (int i = 0; i < nfds; i++) { if (events[i].data.fd == STDIN_FILENO) { char buf[1024]; read(STDIN_FILENO, buf, sizeof(buf)); // 处理数据 } } } ``` #### 关键API详解 - **`epoll_create1(int flags)`**： - 创建epoll实例，返回epfd（文件描述符）。 - `flags`：可设置为`EPOLL_CLOEXEC`（子进程不继承epfd）。 - **`epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)`**： - `op`：操作类型（`EPOLL_CTL_ADD`添加、`EPOLL_CTL_MOD`修改、`EPOLL_CTL_DEL`删除）。 - `event`：指定监听的事件类型（如`EPOLLIN`可读、`EPOLLOUT`可写）及用户数据。 - **`epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout)`**： - 返回就绪事件的个数，并将事件填充到`events`数组中。 - `timeout`：-1表示阻塞，0表示非阻塞，>0表示超时时间（毫秒）。 ### 四、epoll的高性能原因 1. **O(1)事件检测**： 通过就绪链表直接获取活跃fd，无需遍历所有fd（select/poll需$O(n)$遍历）。 2. **内核-用户共享内存**： `epoll_wait()`返回时，内核将就绪事件复制到用户空间，避免数据拷贝（select/poll每次需复制整个fd集合）。 3. **无最大fd数量限制**： 仅受系统最大文件描述符数量限制（select通常限制为1024）。 ### 五、epoll反应堆模型（Reactor Pattern） 引用[1]提到的“反应堆模型”是一种事件驱动的设计模式，核心流程： ```mermaid graph LR A[epoll_wait] --> B{事件就绪} B -->|可读事件| C[accept/read] B -->|可写事件| D[write] ``` 改进为反应堆模型后： ```mermaid graph LR A[epoll_wait] --> B{事件类型} B -->|新连接| C[accept并注册读事件] B -->|数据到达| D[read并注册写事件] B -->|可写| E[write并移除写事件] ``` ### 六、最佳实践 1. **ET模式必须使用非阻塞I/O**： 避免因未读完数据导致后续事件丢失。 ```c // 设置非阻塞fd fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_NONBLOCK); ``` 2. **避免事件饥饿**： 在ET模式下，若某个fd持续有数据到达，可能饿死其他fd。需合理分配处理时间。 3. **多线程扩展**： 使用多个线程各自运行独立的epoll循环（如Nginx的多worker模型）。 --- §§相关问题§§ 1. epoll与select/poll的性能对比差异具体体现在哪些场景？ 2. 如何实现一个基于epoll的简易HTTP服务器？ 3. epoll在边缘触发模式下如何处理数据读写？ 4. epoll是否适用于Windows或macOS系统？</think>### Linux epoll 模型详解：工作原理与使用方法 --- #### 一、epoll 核心概念 epoll 是 Linux 内核提供的高性能 I/O 事件通知机制，用于解决传统 `select`/`poll` 的三大瓶颈： 1. **遍历开销**：每次调用需遍历所有 fd（$O(n)$ 复杂度） 2. **数量限制**：`select` 默认仅支持 1024 个 fd 3. **数据拷贝**：每次需将 fd 集合从用户空间复制到内核空间 epoll 通过以下设计实现高效管理： - **红黑树**：存储所有监听 fd（$O(\log n)$ 插入/删除） - **就绪链表**：仅返回活跃 fd（避免全量遍历） - **内存映射**：内核与用户空间共享就绪列表（零拷贝）[^1][^2] --- #### 二、epoll 工作流程 ```mermaid graph LR A[epoll_create] --> B[创建红黑树+就绪链表] B --> C[epoll_ctl] C --> D[添加/修改/删除 fd] D --> E[epoll_wait] E --> F[检查就绪链表] F --> G[返回活跃事件] ``` ##### 1. **创建 epoll 实例** ```c int epfd = epoll_create1(0); // 参数 flags 通常为 0 ``` - 创建红黑树存储监听 fd - 创建就绪链表存储活跃事件 ##### 2. **管理监听 fd（`epoll_ctl`）** ```c struct epoll_event ev; ev.events = EPOLLIN | EPOLLET; // 监听可读事件+边缘触发 ev.data.fd = sockfd; // 关联自定义数据 epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &ev); // 添加监听 ``` - **操作类型**： - `EPOLL_CTL_ADD`：添加 fd - `EPOLL_CTL_MOD`：修改事件 - `EPOLL_CTL_DEL`：删除 fd - **事件类型**： - `EPOLLIN`：数据可读 - `EPOLLOUT`：数据可写 - `EPOLLET`：边缘触发模式（默认水平触发） - `EPOLLRDHUP`：对端关闭连接 ##### 3. **等待事件就绪（`epoll_wait`）** ```c #define MAX_EVENTS 64 struct epoll_event events[MAX_EVENTS]; int n = epoll_wait(epfd, events, MAX_EVENTS, -1); // -1=阻塞等待 for (int i = 0; i < n; i++) { if (events[i].events & EPOLLIN) { handle_read(events[i].data.fd); // 处理可读事件 } } ``` - **返回值**：就绪事件数量 - **参数**： - `timeout=-1`：阻塞等待 - `timeout=0`：非阻塞检查 - `timeout>0`：超时时间（毫秒） --- #### 三、触发模式详解 ##### 1. **水平触发（LT，默认模式）** - **特点**：只要 fd 就绪，就会持续通知 - **场景**：适合编程简单场景 ```c // 示例：未完全读取数据时持续触发 while ((n = read(fd, buf, BUF_SIZE)) > 0) { process_data(buf, n); } ``` ##### 2. **边缘触发（ET）** - **特点**：仅在 fd 状态变化时通知一次 - **要求**：必须使用**非阻塞 I/O** 循环读取 ```c // 设置非阻塞模式 fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_NONBLOCK); // 循环读取直到 EAGAIN while (1) { n = read(fd, buf, BUF_SIZE); if (n == -1) { if (errno == EAGAIN) break; // 数据已读完 else handle_error(); } process_data(buf, n); } ``` --- #### 四、epoll 高性能原理 1. **$O(1)$ 事件检测** 就绪链表直接返回活跃 fd，无需遍历所有连接。 2. **零拷贝机制** `epoll_wait` 返回时，内核通过共享内存传递就绪事件。 3. **无 fd 数量限制** 仅受系统最大文件描述符数约束（通常 10 万+）。 4. **高效内核回调** 通过回调函数（`callback`）仅将活跃 fd 加入就绪链表。 --- #### 五、完整代码示例（TCP 服务器） ```c #include <sys/epoll.h> #include <fcntl.h> #define MAX_EVENTS 64 int main() { int listen_fd = create_tcp_server(8080); // 创建监听 socket int epfd = epoll_create1(0); // 添加监听 socket struct epoll_event ev; ev.events = EPOLLIN; ev.data.fd = listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev); while (1) { struct epoll_event events[MAX_EVENTS]; int n = epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i = 0; i < n; i++) { if (events[i].data.fd == listen_fd) { // 处理新连接 int conn_fd = accept(listen_fd, NULL, NULL); fcntl(conn_fd, F_SETFL, O_NONBLOCK); // 非阻塞 ev.events = EPOLLIN | EPOLLET; // 边缘触发 ev.data.fd = conn_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev); } else if (events[i].events & EPOLLIN) { // 处理客户端数据 handle_client(events[i].data.fd); } } } } ``` --- #### 六、最佳实践 1. **ET 模式必须搭配非阻塞 I/O** 避免因未读完数据导致后续事件丢失。 2. **合理控制事件循环频率** 使用 `epoll_wait` 超时参数避免 CPU 空转。 3. **多线程扩展** 每个线程独立运行 epoll 循环（如 Nginx 模型）。 4. **避免惊群效应** Linux 4.5+ 支持 `EPOLLEXCLUSIVE` 选项，防止多个进程同时唤醒。 > 通过 epoll 模型，C10K 问题（单机万级并发）在 Linux 上得到高效解决[^2]。实际测试中，epoll 处理 10,000 个活跃连接时，CPU 占用率比 select 低 90%+。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值