结论：应采用单线程事件循环+连接池复用+必要时线程池offload业务逻辑，避免每连接一线程；因后者在数百连接时即因栈内存暴涨、上下文切换、析构崩溃及状态竞争导致性能崩塌。
直接说结论：别用“每个连接一个线程”这种原始做法，它在几百连接时就可能因线程创建/销毁开销和上下文切换拖垮性能；正确路径是「单线程事件循环 + 连接池复用 + 必要时线程池 offload 业务逻辑」。
为什么 std::thread 每连接绑一线程会崩
常见错误是看到“多线程”，就给每个 accept() 返回的 socket 新起一个 std::thread 去 read()/write()。这在 100 连接内看似可行，但实际问题集中爆发：
- Linux 默认线程栈 8MB，1000 连接 ≈ 8GB 内存，还没算锁竞争和调度延迟
-
read()阻塞时线程挂起，但线程对象仍占资源；大量空闲线程让sched_yield和上下文切换成为 CPU 主要消耗 - 连接断开时若没显式
join()或detach()，std::thread析构会直接std::terminate() - 多个线程并发修改同一连接状态（如
is_closed_标志）而无保护，导致状态错乱或 double-close
cpp-httplib 中长连接的线程模型真相
很多人以为 cpp-httplib 的 set_keep_alive(true) 是靠多线程维持的，其实不是：它的 HTTP Server 默认用单线程 epoll（Linux）或 select 驱动事件循环，所有连接共享同一个 I/O 线程。线程池只用于执行用户注册的 handler 函数——也就是你写在 svr.Get(...) 里的那部分逻辑。
这意味着：
立即学习“C++免费学习笔记（深入）”；
- 连接生命周期管理（读超时、心跳检测、关闭清理）全在主线程完成，无锁开销
- 你的 handler 被扔进线程池执行，但 handler 内不能直接操作原始 socket fd —— cpp-httplib 已封装成
const Request&和Response&，数据已拷贝或内存池分配 - 若 handler 执行过久（比如同步 DB 查询），会阻塞整个线程池，建议改用异步 DB 客户端或显式投递到专用工作队列
自己手写 epoll + 线程池时的关键分工
当不用 cpp-httplib、需自建服务时，必须明确划分职责：
- I/O 线程（1 个或少数几个）：只做
epoll_wait()、read()到缓冲区、write()发送、定时器轮询（如用时间轮）、连接状态机更新 —— 这部分绝对不能有阻塞调用 - 业务线程池（固定大小，如
std::thread::hardware_concurrency() - 1）：只处理解包后的请求数据、调用业务逻辑、生成响应体；结果通过线程安全队列或回调通知 I/O 线程发送 - 连接对象本身必须是线程安全的：用原子变量（如
std::atomic_bool closed_）代替互斥锁保护关键状态；避免在业务线程中直接 close() socket fd，统一由 I/O 线程执行
典型错误是让业务线程调用 send()，这既破坏了 I/O 复用模型，又引入 fd 竞态——socket fd 是进程级资源，跨线程 write 可能触发 EAGAIN 或丢包。
粘包 + 心跳 + 定时器的组合陷阱
长连接下这三个问题总是一起出现，且容易被线程模型掩盖：
- 粘包解析必须在 I/O 线程完成：把收到的字节流按协议切分出完整消息后，再整包投递给业务线程；否则业务线程拿到的是半包，无法处理
- 心跳检测不能依赖
std::this_thread::sleep_for()：它会让 I/O 线程停摆，导致所有连接无法读写；必须用epoll的超时机制或时间轮驱动 - 连接空闲超时和心跳超时要区分：前者是连接层（如 60 秒无任何数据），后者是应用层（如 30 秒未收到
"PING"回复）；两者计时器不能混用，否则会误杀活跃连接
最容易被忽略的一点：心跳包的收发必须走同一套缓冲区管理和状态机——很多实现把心跳当成“特殊消息”单独处理，结果心跳响应被粘在业务数据后面，导致超时误判。真正健壮的做法，是让心跳帧也走通用协议解析流程，只是 handler 分支返回空响应。
