epoll多线程Socket服务器请求失败，重复处理connfd问题排查

核心结论 #

问题根源不是“多线程共用connfd”本身——多线程可以安全共用同一个合法的文件描述符（只要操作逻辑合理），真正的问题是connfd的生命周期管理混乱，导致某个线程使用了已经被关闭的无效fd。

错误原因拆解 #

errno=9对应EBADF（无效文件描述符），说明调用recv时传入的connfd已失效：要么已经被关闭，要么从未被正确初始化。结合“同一connfd被多次处理”的现象，常见触发场景有两种：

• 某个线程已经关闭了connfd，但其他线程仍持有该fd并尝试执行读写操作；
• epoll实例中未及时删除已关闭connfd的监听事件，导致多个线程重复收到同一个connfd的可读事件，其中一个线程处理完关闭fd后，另一个线程再处理就触发错误。

常见代码错误点 #

1. epoll事件未同步删除
   处理完connfd后未调用epoll_ctl(epfd, EPOLL_CTL_DEL, connfd, NULL)，或者删除操作未加锁（epoll_ctl不是线程安全接口），导致epoll仍在监听已关闭的fd，后续事件触发时线程拿到无效fd。
2. connfd关闭逻辑无保护
   多个线程同时执行close(connfd)，或者一个线程在执行close的同时，另一个线程正在调用recv。这种情况下，fd可能已被系统回收，后续操作必然报错。
3. 事件分发无互斥
   多线程共用同一个epoll实例时，未用互斥锁保护epoll_wait的结果，导致同一个connfd的事件被多个线程同时取走处理，其中一个线程关闭fd后，另一个线程的操作就会失败。

修复建议 #

• 给epoll操作加锁：用互斥锁保护epoll_ctl和epoll_wait后的事件处理流程，确保同一时间只有一个线程处理某个connfd的事件；
• 规范connfd生命周期：处理流程改为：先调用EPOLL_CTL_DEL从epoll中移除事件，再处理请求，最后执行close(connfd)；或者处理完请求后立即移除事件再关闭；
• 给connfd加状态标记：用原子变量标记connfd是否已关闭，每次操作前先检查状态，避免对无效fd执行recv/close等操作。

内容的提问来源于stack exchange，提问作者wblxwz