单 reactor 线程瓶颈在于主线程需同时处理 accept、read/write，任一操作阻塞即导致全链路卡顿；多 reactor 通过主 reactor 专责 accept、子 reactor 分担 i/o 与业务、计算任务交由独立线程池实现真正并发。
单 Reactor 线程瓶颈在哪
主线程既要 accept 新连接，又要 read/write 所有已连接 socket，一旦某个请求处理稍慢（比如解析 HTTP 头耗时、日志写入阻塞），整个事件循环就卡住，其他连接全得排队等。这不是并发，是“伪并发”——epoll 能监听上万 fd，但线程只有一个，CPU 利用率永远上不去。
多 Reactor + 线程池的分工逻辑
核心不是“多开几个 EventLoop”，而是按职责拆分：
-
主 Reactor（1 个，主线程）：只干一件事——
accept，拿到新连接后，立刻用轮询或负载策略选一个子 Reactor，把 client fd 交给它 -
子 Reactor（N 个，线程池中）：每个绑定独立
epoll实例和独立线程，只负责自己分到的那批连接的read/write和业务逻辑 -
业务处理不放在线程里直接做：如果业务逻辑重（如 JSON 解析、DB 查询），应丢进单独的计算线程池，避免阻塞子 Reactor 的
epoll_wait
注意：EventLoopThreadPool 初始化时就要创建好 N 个 EventLoopThread，每个调用 EventLoop::loop() 进入自己的事件循环，而不是临时 new 线程——否则又回到“一个连接一个线程”的老路。
epoll ET 模式必须配合非阻塞 socket
子 Reactor 中若用 EPOLLET，socket 必须设为非阻塞（fcntl(fd, F_SETFL, O_NONBLOCK)），否则 read 可能因缓冲区空而阻塞，导致整个线程挂死。
常见错误现象：
- 客户端发 100 字节，服务端只
read一次拿走 50 字节，剩余 50 字节留在内核缓冲区 → LT 模式下下次epoll_wait还会通知；ET 模式下不会再次通知，连接就此“静默” - 没检查
read返回值：返回-1且errno == EAGAIN或EWOULDBLOCK才表示数据读完；否则要继续循环读，直到触发该条件
所以 ET 下的读逻辑必须是：
while ((n = read(fd, buf, sizeof(buf))) > 0) { /* 处理数据 */ } if (n == -1 && errno != EAGAIN) { /* 错误处理 */ }
Channel 的事件注册与线程安全边界
Channel 是 Reactor 中封装 fd 和回调的载体，它的 events 字段（如 ReadEvent、WriteEvent）被多个线程修改时极易出错：
- 主线程在
accept后往子 Reactor 的 epoll 添加 fd，需调用epoll_ctl(epfd, EPOLL_CTL_ADD, ...)，同时设置Channel::m_events |= ReadEvent - 子 Reactor 在处理完响应后想发数据，需调用
Channel::writeEventEnable(true)，这会改m_events并触发epoll_ctl(EPOLL_CTL_MOD, ...) - 这两个操作不能跨线程直接读写同一
Channel对象 —— 必须通过线程安全队列（如BlockingQueue<:function>></:function>）将事件变更任务投递给目标EventLoop所在线程执行
换句话说：Channel 的生命周期和事件操作，必须严格绑定在其所属 EventLoop 的线程上下文中。跨线程修改 m_events 或直接调用 epoll_ctl 是典型崩溃源。
真正难的不是写多线程，而是划清“谁在哪个线程改什么”——Reactor 的优雅，全系于这一条边界是否守得住。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
