C++高并发服务器必须采用epoll+多线程Reactor模型，而非“一连接一线程”；否则超千连接时CPU陷于上下文切换，业务逻辑无法获得足够时间片。
直接说结论：C++高并发服务器不能靠“来一个连接开一个线程”硬堆，必须用事件驱动（epoll）+ 多线程 Reactor 模型。否则连接数一过千，CPU 就在上下文切换里打转，业务逻辑根本抢不到时间片。
为什么 std::thread + blocking socket 一定撑不住万级连接
每个 std::thread 默认占 8MB 虚拟栈空间，1000 个连接就是 8GB 地址空间；实际压测中，线程数超 300 后，pthread_create 开始失败，errno 常见为 EAGAIN（资源临时不可用）。更隐蔽的问题是：阻塞式 recv 会让线程挂起，但调度器仍要为其维护上下文，大量空闲线程持续消耗 CPU 调度开销——这不是性能差，是模型错配。
- 不要用
select或poll替代：它们仍是 O(n) 扫描，fd 数量上万时内核拷贝和用户态遍历成本爆炸 - 不要手动实现状态机轮询：非阻塞 socket 配合
epoll_wait是基础，但裸写EPOLLIN/EPOLLOUT切换、缓冲区管理、半包粘包处理极易出错 - 避免在主线程做业务逻辑：accept 后立刻把 fd 分发出去，主线程只做连接接入，否则会成为单点瓶颈
epoll + 多 Reactor 线程模型怎么搭才不翻车
核心是分工明确：主线程只跑一个 epoll_wait 监听 listen_fd，用 accept4 带 SOCK_NONBLOCK | SOCK_CLOEXEC 标志创建新连接，然后通过 eventfd 或管道把 fd 安全传递给某个 Sub Reactor 线程。每个 Sub Reactor 线程独立持有自己的 epoll_fd，注册该连接的读写事件。
- 必须用边缘触发（ET）模式：配合非阻塞 socket，避免重复通知；但每次
read必须循环到EAGAIN，否则可能丢数据 - 每个连接需配独立
Buffer：读缓冲区要支持自动扩容（如从 4KB 起步，上限 64KB），写缓冲区要用链表或 ring buffer，防止大响应体阻塞整个事件循环 - 定时器必须走
timerfd_create：和 epoll 统一事件源，不要另起线程轮询std::chrono，否则精度差且难同步
线程间安全传递 fd 的坑在哪
常见错误是直接把 fd 整数通过队列传给另一个线程，结果目标线程调用 epoll_ctl(EPOLL_CTL_ADD) 失败，报 EBADF。原因：fd 是进程级资源，跨线程传递本身合法，但若原线程已 close 或子线程未正确设置 CLOEXEC，就会失效。
立即学习“C++免费学习笔记（深入）”；
- 务必在
accept4时带上SOCK_CLOEXEC，避免 fork 子进程时意外继承 - 用
sendmsg+SCM_RIGHTS传递 fd 最可靠，比共享整数或管道更底层、无竞态 - 如果用
eventfd唤醒 Sub Reactor，记得每次 write 后 read 清空，否则下次唤醒不触发 - 不要在 Sub Reactor 线程里直接
close主线程传来的 fd：应由所属 Reactor 自己管理生命周期
Buffer 和内存管理最容易被忽略的细节
很多实现卡在吞吐量上不去，不是 epoll 写得不对，而是 Buffer 拷贝太多、new/delete 太频繁。一个连接收 1MB 文件，如果每次只 read 1KB 就 memcpy 到业务缓冲区，光内存拷贝就干掉 1000 次系统调用开销。
- 读缓冲区建议用
mmap预分配大块内存，按页对齐，连接复用时直接 reset 指针，避免反复 malloc - 写缓冲区优先用
splice或sendfile：文件直送 socket，绕过用户态拷贝；若不行，至少用writev一次提交 header + body，减少 syscall 次数 - 连接对象必须池化：
new Connection是性能毒药，用对象池（如boost::pool或自研 slab allocator）复用，避免锁竞争和碎片
真正卡住人的从来不是 epoll API 怎么调，而是 Buffer 边界判断错一次导致粘包、timerfd 未清空导致定时器堆积、fd 传递漏了 CLOEXEC 导致连接泄漏——这些点不写进日志很难复现，但线上一出就是雪崩。
