不能为每个Socket开一个线程，核心动因是避免线程创建/切换开销过大：1000个连接约耗8GB内存（默认栈8MB），上下文切换成瓶颈，且系统常有线程数硬限制；select、poll、epoll应按平台与规模选型：Linux万级连接首选epoll（O(1)增删、O(k)就绪获取），跨平台优先poll，仅兼容老系统用select。
为什么不能为每个Socket开一个线程
单线程里处理多个 socket 的核心动因，是避免线程创建/切换开销过大。Linux 下线程栈默认 8MB，1000 个连接 ≈ 8GB 内存；上下文切换在高并发时成为瓶颈。更关键的是，很多系统（如嵌入式或容器环境）对线程数有硬限制，pthread_create 可能直接失败。
select / poll / epoll 该怎么选
三者本质都是 I/O 多路复用，但适用场景差异明显：
-
select：跨平台，但 fd_set 有FOPEN_MAX限制（通常 1024），且每次调用需重置整个集合，时间复杂度 O(n) -
poll：无 fd 数量硬限制，但同样需遍历全部struct pollfd数组，O(n)；Windows 上支持比epoll好 -
epoll（Linux）：基于红黑树+就绪链表，O(1) 增删、O(k) 获取就绪事件（k 是活跃 socket 数），适合万级连接
若目标平台确定是 Linux 且连接数可能过千，直接用 epoll；否则优先 poll，仅需兼容老系统时才退回到 select。
epoll 使用中容易漏掉的三个细节
epoll 看似简单，但实际部署常因细节翻车：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 忘记设置 socket 为非阻塞模式：
fcntl(fd, F_SETFL, O_NONBLOCK)—— 否则read()/write()在缓冲区空/满时会阻塞，整个线程卡死 -
epoll_ctl(EPOLL_CTL_ADD)后没设EPOLLET（边缘触发）？若用水平触发（LT），只要 socket 可读就会持续通知，必须一次性读完所有数据，否则下次循环又触发 —— 容易导致 busy-loop - 关闭 socket 后未从 epoll 实例中删除：
epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fd, nullptr)—— fd 被复用后，旧事件可能误触发，引发访问已释放内存
如何安全地在单线程里读写多个 socket
关键不是“怎么注册”，而是“怎么处理就绪事件时不阻塞、不遗漏”：
- 每次
epoll_wait()返回后，**必须循环处理所有就绪事件**，不能只处理第一个 —— 因为一次调用可能返回多个epoll_event - 对每个可读 socket，用
recv(fd, buf, len, MSG_DONTWAIT)或检查errno == EAGAIN/EWOULDBLOCK判断是否读完；不可假设一次recv就收全包 - 写操作要维护发送缓冲区：当
send()返回值小于待发字节数，说明内核缓冲区满，需把剩余数据暂存，并注册EPOLLOUT事件；等可写再继续发，否则丢数据
真正难的从来不是监听多个 socket，而是每个 socket 的状态机管理——读到半包、写被中断、对端断连、超时重传……这些逻辑堆叠起来，比多线程模型更考验设计精度。
