C++怎么使用epoll_C++Linux网络教程【高效】

epoll不是c++标准库组件，而是linux内核系统调用，需通过c接口epoll_create1、epoll_ctl、epoll_wait使用，头文件为；需注意错误处理、et/lt模式选择、内存生命周期及事件循环完整性。

epoll 不是 C++ 标准库的一部分，C++ 本身没有 epoll —— 它是 Linux 内核提供的系统调用，必须通过 C 风格的 syscall 或封装好的 C 接口使用。

怎么在 C++ 里调用 epoll 函数

你得直接用 Linux 的 C 接口：epoll_create1、epoll_ctl、epoll_wait。C++ 编译器完全兼容这些函数，头文件是 <sys></sys>，链接不需要额外库（内核接口，无 libc 依赖）。

常见错误现象：epoll_create1 返回 -1 且 errno == ENOSYS —— 这说明内核版本太低（

• 必须 #include 、、、
• epoll_create1(0) 比旧的 epoll_create 更安全，推荐始终传 0
• 监听 socket 必须设为非阻塞（fcntl(fd, F_SETFL, O_NONBLOCK)），否则 epoll_wait 可能不触发可读，或 read 卡住
• 别把 epoll_fd 当普通 fd 传给 close() 以外的任何系统调用（比如误塞进 select）

epoll_ctl 的 EPOLL_CTL_MOD 容易出错

很多人以为 EPOLL_CTL_MOD 只改事件掩码，其实它要求 fd 已经在 epoll 实例中注册过；如果没注册就用 MOD，会返回 ENOENT。

立即学习“C++免费学习笔记（深入）”；

使用场景：比如连接刚建立时只监听可读，收到请求后想加监听可写（如响应大文件），就得用 MOD 更新 events 字段。

• 第一次注册必须用 EPOLL_CTL_ADD，不能跳过
• epoll_event 结构体里的 data.fd 和 data.ptr 二选一用；混用或不初始化容易导致 epoll_wait 返回脏数据
• 修改事件时，epoll_event.events 必须显式写出全部要监听的事件（比如原来有 EPOLLIN，现在要加 EPOLLOUT，就得写 EPOLLIN | EPOLLOUT，不是只写 EPOLLOUT）

epoll_wait 返回后怎么安全处理就绪事件

返回值是就绪事件数量，但 epoll_event 数组里每个元素的 data 字段内容取决于你注册时填的是 fd 还是 ptr —— 这个差异直接影响你怎么取上下文。

性能影响：如果每次 epoll_wait 后都遍历所有就绪项做 read/write，但某个连接一次只读到一半包，又没继续循环处理，就会丢事件或卡死。

• 永远检查 ret > 0 再遍历，ret == 0 表示超时（如果你设了 timeout），ret == -1 要看 errno（EINTR 可重试，EBADF 说明 fd 被提前关了）
• 对每个就绪 fd，必须循环 read 直到返回 -1 且 errno == EAGAIN（非阻塞语义），不能只读一次
• 如果用 data.ptr 存自定义结构体指针，确保该内存生命周期覆盖整个 epoll 生命周期（别在连接关闭后还让 epoll 持有悬垂指针）

为什么不用 epoll 封装库（如 libev、libuv）

不是不能用，而是封装库会隐藏关键细节：比如它们默认帮你做边缘触发（ET）还是水平触发（LT）、怎么管理 fd 生命周期、buffer 怎么复用。一旦出问题，你得钻进封装层才能定位。

兼容性影响：libuv 跨平台，但在 Linux 上实际仍走 epoll；而手写的话，你可以严格控制 ET/LT 模式、避免不必要的 epoll_ctl 调用（比如反复 MOD 同一个 fd），这对百万连接场景很关键。

• 如果你只需要跑在 Linux 服务器上，且对延迟和连接数敏感（比如游戏网关、实时消息代理），手写更可控
• 如果项目要兼顾 macos（kqueue）或 windows（IOCP），或者开发节奏紧，libuv 是更省心的选择
• 别为了“高效”强行手写——没测过 epoll_wait 在 10w 连接下的唤醒延迟、没压测过 buffer 分配策略，所谓高效只是幻觉

真正难的不是调几个函数，是理解每个 epoll_ctl 调用背后内核状态的变化，以及如何让用户态逻辑和内核事件通知节奏对齐。漏掉一次 EAGAIN 判断，或少清一个 EPOLLET 标志，线上就可能挂半天。