C++如何在一个线程中处理多个Socket的I/O

不能为每个Socket开一个线程，核心动因是避免线程创建/切换开销过大：1000个连接约耗8GB内存（默认栈8MB），上下文切换成瓶颈，且系统常有线程数硬限制；select、poll、epoll应按平台与规模选型：Linux万级连接首选epoll（O(1)增删、O(k)就绪获取），跨平台优先poll，仅兼容老系统用select。

先抛个总结：在单线程里处理多个 Socket，本质上是在“资源成本”和“并发能力”之间找平衡。很多新手第一反应是“来一个连接就开一个线程”，但真这么干，系统很快就会被拖垮。下面把核心原因和选型逻辑拆开细说。

为什么不能为每个Socket开一个线程

说白了，核心原因就一个：线程这东西，创建和切换的成本太高了。Linux 下线程默认栈大小是 8MB，假设有 1000 个连接，光栈空间就要吃掉 8GB 内存，这还没算线程本身的控制块开销。更要命的是，当线程数超过 CPU 核数几倍时，上下文切换就会变成系统的主瓶颈——CPU 大部分时间都在“换人”，而不是真正干活。此外，很多环境（比如嵌入式设备或者容器）对线程数有硬性限制，直接搞pthread_create 很可能就返回失败。所以，不是“不能”，而是“不该”。

select / poll / epoll 该怎么选

这三个都是 I/O 多路复用的工具，但适用的场景天差地别：

• select：好处是跨平台，缺点也很明显——fd_set 有上限（通常是 1024），而且每次调用都要重新初始化集合，遍历所有 fd 检查状态，时间复杂度是 O(n)，连接一多就吃力。
• poll：突破了 fd 数量的硬限制，但依然是遍历所有 struct pollfd，O(n) 的复杂度没跑。好处是在 Windows 上支持得比 epoll 好，跨平台场景下是个更稳妥的选择。
• epoll（Linux）：基于红黑树+就绪链表，增删事件是 O(1)，获取就绪事件只关心活跃的 socket（即 O(k)，k 是活跃数）。连接数一旦上千，epoll 的优势就非常明显。

所以到底选哪个？看你的目标平台和规模。Linux 环境下连接数能过千的，直接上 epoll；需要跨平台又不想太折腾，优先 poll；除非你还在维护那种古董级别的系统，否则就别碰 select 了。

epoll 使用中容易漏掉的三个细节

epoll 的 API 看着就那么几个函数，但实际项目里翻车往往都在这些“不起眼的地方”：

• 忘了把 Socket 设为非阻塞模式——这是最常见的坑。如果不执行 fcntl(fd, F_SETFL, O_NONBLOCK)，那么 read() 或 write() 在缓冲区空或满时会直接阻塞，整个线程就被卡死了，其他所有 socket 都得等着。
• 用了水平触发（LT）模式却没读完数据——epoll 默认是 LT，意味着只要 socket 可读，它就会一直通知你。如果你每次只读一点，下次循环又触发，很容易陷入 busy-loop。换成边缘触发（ET）能减少重复通知，但必须确保一次把数据读干净。
• 关闭 socket 后没从 epoll 实例里删除——epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fd, nullptr) 这一步很容易忘。等 fd 被复用后，旧的事件可能突然冒出来，指向一块已经被释放的内存，后果就是野指针崩溃。

如何安全地在单线程里读写多个 socket

本质不在于“怎么注册事件”，而在于“怎么处理就绪事件时才不会阻塞或漏掉”：

• 每次 epoll_wait() 返回后，必须把本轮所有就绪事件全部处理完，不能只处理第一个——因为一次调用可能给你多个就绪的 socket。
• 对于可读的 socket，用 recv(fd, buf, len, MSG_DONTWAIT) 或者检查 errno == EAGAIN/EWOULDBLOCK 来判断数据是否已经读完。永远不要假设一次 recv 就能收到一个完整的报文。
• 写操作要维护发送缓冲区：当 send() 返回值小于待发送的字节数时，说明内核缓冲区满了。这时必须把剩下的数据先存起来，然后注册 EPOLLOUT 事件，等 socket 可写时再继续发，否则数据就丢了。

说句实在话，监听多个 socket 本身一点也不难，真正考验人的是每个 socket 的状态机管理——读到半包怎么办、写被中断了怎么恢复、对端突然断连怎么处理、超时重传怎么搞……这些逻辑堆在一起，复杂度比多线程模型高出一大截。单线程处理 I/O 的路子，对设计精度要求非常高。