自己趟过epoll的坑

关注

转载最新推荐文章于 2026-03-28 10:19:33 发布 1.3w 阅读 AI 写同款· GEO 优化 ›

【向量数据库】Milvus向量数据库 ① 从入门到实战 Milvus是专为海量高维向量设计的开源数据库，支持AI搜索、图像识别、推荐系统等场景。相比传统关系型数据库（如PostgreSQL），它更高效处理语义检索、非结构化数据存储，可毫秒级响应亿级向量查询。单机场景下，推荐配置8GB内存/32GB硬盘，支持FAISS/HNSW等索引算法，支持GPU加速。本文涵盖优快云专属部署教程（CentOS脚本/配置调优），提供避坑指南与扩展资源，并对比分析与传统数据库差异。适合算法工程师、AI开发人员快速上手，附官方下载与性能测试技巧，手把手教你搭建高效向量检索系统！阅读详情

坑的背景

本人用epoll来实现多路复用，epoll触发模式有两种：

ET（边缘模式）
LT（水平模式）

LT模式

是标准模式，意味着每次epoll_wait()返回后，事件处理后，如果之后还有数据，会不断触发，也就是说，一个套接字上一次完整的数据，epoll_wait()可能会返回多次，直到没有数据为止。

ET模式

也称高效模式，有数据过来后，epoll_wait()会返回一次，一段时间内，该套接字就算有数据源源不断地过来，epoll_wait()也不会返回了。这里注意，是一段时间，不代表这个套接字上有数据就只触发一次。时间过长，还是会返回多次的。比如我写FTP用了epoll+多线程，但是每次套接字上有信息就开线程处理，同一时间内希望一个套接字只被一个线程持有，但是因为文件传输时间过长，就算使用ET模式，套接字还是会返回多次。这里要特别强调一个参数EPOLLONESHOT，如果要保证套接字同一时段只被一个线程处理，必须加上。

解决方案：给accept()后的套接字加上参数EPOLLONESHOT，线程结束后处理完之后，再重置EPOLLONESHOT属性，但是，千万不可以给listen()后的监听套接字设置此属性，这会造成同一时刻只能处理一个连接的情况。

深入理解EPOLLONESHOT事件

即使使用ET模式，一个socket上的某个事件还是可能被触发多次，这是跟数据报的大小有关系，常见的情景就是一个线程，而在数据的处理过程中该socket上又有新数据可读（EPOLLIN再次被触发），此时另外一个线程被唤醒处理这些新的数据，于是出现了两个线程同时操作一个socket，为了避免这种情况，就可以采用epoll的EPOLLONESPOT事件。同时要注意，注册了EPOLLONESHOT事件的socket一旦被某个线程处理完毕，该线程就应该立即重置这个socket的EPOLLONESHOT的事件，以确保这个socket下次可读时，其EPOLLIN事件被触发，进而让其他的工作线程有机会继续处理这个socket。

网络事件EAGIN

在一个非阻塞的socket上调用read/write函数, 返回EAGAIN或者EWOULDBLOCK(注: EAGAIN就是EWOULDBLOCK)从字面上看, 意思是:EAGAIN: 再试一次，EWOULDBLOCK: 如果这是一个阻塞socket, 操作将被block，perror输出: Resource temporarily unavailable.

小结:

这个错误表示资源暂时不够，能read时，读缓冲区没有数据，或者write时，写缓冲区满了。遇到这种情况，如果是阻塞socket，read/write就要阻塞掉。而如果是非阻塞socket，read/write立即返回-1，同时errno设置为EAGAIN。所以，对于阻塞socket，read/write返回-1代表网络出错了。但对于非阻塞socket，read/write返回-1不一定网络真的出错了。可能是Resource temporarily unavailable。这时你应该再试，直到Resource available。

EAGAIN: 再试一次，EWOULDBLOCK: 如果这是一个阻塞socket, 操作将被block，perror输出: Resource temporarily unavailable。这个错误表示资源暂时不够，能read时，读缓冲区没有数据，或者write时，写缓冲区满了。遇到这种情况，如果是阻塞socket，read/write就要阻塞掉。而如果是非阻塞socket，read/write立即返回-1，同时errno设置为EAGAIN。所以，对于阻塞socket，read/write返回-1代表网络出错了。但对于非阻塞socket，read/write返回-1不一定网络真的出错了。可能是Resource temporarily unavailable。这时你应该再试，直到Resource available。

综上，对于non-blocking的socket，正确的读写操作为:
读：忽略掉errno = EAGAIN的错误，下次继续读
写：忽略掉errno = EAGAIN的错误，下次继续写

对于select和epoll的LT模式，这种读写方式是没有问题的。但对于epoll的ET模式，这种方式还有漏洞。

epoll的两种模式LT和ET

二者的差异在于level-trigger模式下只要某个socket处于readable/writable状态，无论什么时候进行epoll_wait都会返回该socket；而edge-trigger模式下只有某个socket从unreadable变为readable或从unwritable变为writable时，epoll_wait才会返回该socket。如下两个示意图:
从socket读数据:

从socket写数据:

所以，在epoll的ET模式下，正确的读写方式为:
读：只要可读，就一直读，直到返回0，或者 errno = EAGAIN 写:只要可写，就一直写，直到数据发送完，或者 errno = EAGAIN。

正确的读：

 n = 0; 
while ((nread = read(fd, buf + n, BUFSIZ-1)) > 0) { 
if (nread == -1 && errno != EAGAIN) 
{ 
   perror("read error"); 
}
   n += nread; 
}

正确的写：

 int nwrite, data_size = strlen(buf); 
n = data_size; 
while (n > 0) 
{ 
   nwrite = write(fd, buf + data_size - n, n); 
   if (nwrite < n) 
  { 
     if (nwrite == -1 && errno != EAGAIN) 
     { 
        perror("write error"); 
     } 
     break; 
  } 
  n -= nwrite; 
}

accept上的问题

阻塞模式 accept 存在的问题
考虑这种情况：TCP连接被客户端夭折，即在服务器调用accept之前，客户端主动发送RST终止连接，导致刚刚建立的连接从就绪队列中移出，如果套接口被设置成阻塞模式，服务器就会一直阻塞在accept调用上，直到其他某个客户建立一个新的连接为止。但是在此期间，服务器单纯地阻塞在accept调用上，就绪队列中的其他描述符都得不到处理。

解决方案：把监听套接口设置为非阻塞，当客户在服务器调用accept之前中止某个连接时，accept调用可以立即返回-1，这时源自Berkeley的实现会在内核中处理该事件，并不会将该事件通知给epoll，而其他实现把errno设置为ECONNABORTED或者EPROTO错误，我们应该忽略这两个错误。

ET模式下accept存在的问题。

考虑这种情况：多个连接同时到达，服务器的TCP就绪队列瞬间积累多个就绪连接，由于是边缘触发模式，epoll只会通知一次，accept只处理一个连接，导致TCP就绪队列中剩下的连接都得不到处理。
解决办法是用while循环抱住accept调用，处理完TCP就绪队列中的所有连接后再退出循环。如何知道是否处理完就绪队列中的所有连接呢？accept返回-1并且errno设置为EAGAIN就表示所有连接都处理完。

综合以上两种情况，服务器应该使用非阻塞地accept，accept在ET模式下的正确使用方式为：

 while ((conn_sock = accept(listenfd,(struct sockaddr *) &remote, (size_t *)&addrlen)) > 0)
{ 
   handle_client(conn_sock); 
} 
if (conn_sock == -1) 
{ 
   if (errno != EAGAIN && errno != ECONNABORTED && errno != EPROTO && errno != EINTR) 
   perror("accept"); 
}

一道腾讯后台开发的面试题:

使用Linux epoll模型，水平触发模式；当socket可写时，会不停的触发socket可写的事件，如何处理？
+ 第一种最普遍的方式：
需要向socket写数据的时候才把socket加入epoll，等待可写事件。接受到可写事件后，调用write或者send发送数据。当所有数据都写完后，把socket移出epoll。
这种方式的缺点是，即使发送很少的数据，也要把socket加入epoll，写完后在移出epoll，有一定操作代价。

第二种的方式：
开始不把socket加入epoll，需要向socket写数据的时候，直接调用write或者send发送数据。如果返回EAGAIN，把socket加入epoll，在epoll的驱动下写数据，全部数据发送完毕后，再移出epoll。
这种方式的优点是：数据不多的时候可以避免epoll的事件处理，提高效率。

我自己代码的问题

因为我之前才用的是非阻塞ET模式，这样我在发送缓冲数据的数据，会出现EAGAIN的问题。这个问题并不可怕，最可怕的是会发生，因为上面已经有方法解决。为了看起来方便我这边再拷贝一份。但是我源代码采用的writev源代码下载地址614行进行发送，根本无法才采用下面的方法。

 int nwrite, data_size = strlen(buf); 
n = data_size; 
while (n > 0) 
{ 
   nwrite = write(fd, buf + data_size - n, n); 
   if (nwrite < n) 
  { 
     if (nwrite == -1 && errno != EAGAIN) 
     { 
        perror("write error"); 
     } 
     break; 
  } 
  n -= nwrite; 
}