--
第一章：思想蜕变------从硬编码轮询走向真正的 Reactor 反应堆
1. 为什么"过程化"的 Epoll 是一颗架构定时炸弹？
在刚接触多路复用时，绝大多数同学写出的第一版 epoll 主事件循环往往长成这样：
cpp
// 典型的过程化硬编码写法（架构反模式）：
for (int i = 0; i < nready; i++) {
int fd = events[i].data.fd;
if (fd == listen_fd) {
AcceptHandler(); // 迎宾
} else if (events[i].events & EPOLLIN) {
RecvHandler(fd); // 接收
} else if (events[i].events & EPOLLOUT) {
SendHandler(fd); // 发送
}
}这段代码看似逻辑严密，但在真实的工业级服务器中，它潜藏着三大致命缺陷：
- 严重违背"开闭原则"（OCP） ：
主事件循环承担了所有"类型判断"的脏活累活。如果明天服务器新增一个 UDP 监听套接字、后天加入一个 Linux 原生定时器套接字（timerfd），或者需要处理线程唤醒描述符（eventfd），你就必须不断往这个主循环里堆叠else if。核心调度引擎被反复修改，极易引发回归 Bug。 - 状态与描述符强行剥离 ：
在 TCP 流式协议中，数据是零碎到达的。一个套接字何时收到完整报文？未发完的数据存在哪里？如果是裸fd轮询，你必须在全局定义大量的裸容器（如全局哈希表、二维数组）来记录每个fd的状态，导致全局变量满天飞，代码极其脆弱。 - 业务逻辑与网络 I/O 深度耦合 ：
一旦在RecvHandler(fd)内部直接解析协议并计算结果，整个网络底层就变成了业务的附庸。如果你要把这个服务器从"回显服务器"改成"HTTP 服务器"，底层所有的通信逻辑全要推倒重来。
2. Reactor 反应堆模式的核心哲学
Reactor（反应堆）模式 ，本质上是一种基于事件分发的多路复用架构。它的设计精髓可以浓缩为一句话：
"反应堆引擎本身是盲目的：它不关心任何套接字的具体身份，只负责在事件就绪时，无脑触发绑定在每个套接字身上的专属行为！"
这正是软件工程中著名的好莱坞原则（Hollywood Principle）------"Don't call us, we'll call you"：
-
建立关系时（初始化 / 接入时） ：我们为每个套接字打包好专属的"会话容器"（
Connection），并在容器里塞进三个专门应对读、写、异常 的行为锦囊（std::function回调函数）； -
发生事件时（主循环调度）：主引擎只需要从就绪事件中拿到容器指针，哪个事件就绪了，就直接撕开哪个锦囊执行：
- 触发
EPOLLIN：无脑调用conn->_read_cb(conn)； - 触发
EPOLLOUT：无脑调用conn->_write_cb(conn)； - 触发异常：无脑调用
conn->_except_cb(conn)。
这样做有什么天大的好处？
- 如果这个连接是
listen_fd，它的读锦囊被绑定了AcceptHandler； - 如果这个连接是普通客户端，它的读锦囊被绑定了
RecvHandler。 - 主事件循环彻底实现了"零特判" ！它不需要一行
if (fd == listen_fd)，直接达成如同 C++ 虚函数多态一般的极致解耦。
第二章：关键机制推导------Reactor 内部的核心齿轮如何咬合？
1. 为什么必须将套接字与独立 Buffer 强绑定？
TCP 是一个面向无边界字节流的传输层协议。这就意味着：
- 你给客户端发了一句
"hello\n"，底层可能被拆成两个 TCP 分节到达（半包）； - 客户端连续发了
"aaa\n"和"bbb\n"，底层可能合并在一个数据包中到达（粘包）。
如果在调用 read 读到半截数据时，直接在栈上定义一个临时局部变量 char buf[1024]，函数一退出，读到的半截数据就会随之灰飞烟灭！
解法 ：
每个客户端连接必须拥有专属于自己的独立会话储物柜（Connection），且内部标配两个独立的生命周期缓冲区：
-
_inbuffer（输入缓冲仓） ：所有网络读进来的字节，无论残缺还是完整，统统无脑追加到这里。随后由应用层协议提取器（如查找
\n定界符或解析二进制包头长度）从中不断裁剪完整报文。没凑齐完整报文的数据，安安静静留在_inbuffer里等待下一次事件触发补齐。 -
_outbuffer（输出缓冲仓） ：上层业务处理完毕后，坚决禁止直接调用
write(fd, ...)强发！而是先统一推入本连接的_outbuffer，再由专属发送逻辑统一调度排空。
2. 输出状态机：为什么不能长期监听 EPOLLOUT？
这是 Linux 网络编程中最容易让新手系统陷入死锁或 CPU 崩溃的核心点。
致命现象：
如果你在把客户端套接字挂载到 epoll 时，直接图省事写了：
cpp
// 严重错误写法！
epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, EPOLLIN | EPOLLOUT | EPOLLET);启动之后你会发现：明明没有任何客户端发数据，系统的单核 CPU 利用率瞬间飙升至 100%！
底层本质：
- 读事件就绪（
EPOLLIN） ：只有当对方真的发了数据过来，内核接收缓冲区非空时才成立，这是偶发事件； - 写事件就绪（
EPOLLOUT） ：只要内核发送缓冲区有剩余空间，写事件就永久成立！而在绝大多数正常网络环境下，发送缓冲区 99% 的时间都是空的。 - 如果你长期监听
EPOLLOUT，epoll_wait会以微秒级的速度疯狂唤醒返回，主循环陷入无限空转，直接把 CPU 跑死。
工业级正确解法：按需注册输出状态机
我们设计了一套"首发直刷，满仓托管，排空注销"的输出状态机闭环：
text
业务产生响应数据
│
▼
推入 conn->_outbuffer
│
▼
尝试直接循环调用 write 发送
│
┌─────────────┴─────────────┐
▼ ▼
[所有数据全部发完] [内核发送缓冲区塞满]
_outbuffer.empty() == true write 返回 -1 且 errno == EAGAIN
│ │
▼ ▼
无需挂载 EPOLLOUT 调用 epoll_ctl(MOD)
(保持仅监听 EPOLLIN) 追加对 EPOLLOUT 的关心！托管给内核
│
▼
内核写缓冲腾出空位，唤醒 EPOLLOUT
│
▼
触发 SendHandler 继续排空
│
▼
全部发完后：
立即 epoll_ctl(MOD)
注销 EPOLLOUT！重归平静！3. 系统调用原型详细与大白话
在非阻塞 Reactor 的状态流转中，控制描述符阻塞状态的核心系统调用是 fcntl。
cpp
#include <unistd.h>
#include <fcntl.h>
int fcntl(int fd, int cmd, ... /* arg */ );-
系统调用详细说明：
-
fd：被操作的目标文件描述符； -
cmd：控制命令。在网络编程中，最常用的是： -
F_GETFL：获取目标文件描述符当前的文件状态标志（File Status Flags）； -
F_SETFL：设置目标文件描述符的文件状态标志； -
arg：第三个参数是可选的整数，用于传入更新后的状态掩码（如O_NONBLOCK表示非阻塞 I/O）； -
返回值 ：成功时依赖于
cmd的不同，F_GETFL返回对应的标志位集合；F_SETFL成功返回 0；调用失败返回 -1，并设置errno。 -
大白话说明 ：
这个函数是内核文件属性的"调控阀门"：先用
F_GETFL把套接字原本的属性摸清楚，再通过按位或（|）打上"非阻塞"的标签，最后用F_SETFL塞回内核，彻底让这个套接字开启"绝不干等、没数据立刻报错返回"的高速模式。
第三章：血泪复盘------Reactor 实战中踩平的四大高危深坑
1. 深坑一：epoll_data 联合体类型覆盖导致段错误（SIGSEGV: 0x3）
案发现场：
我们在初始化连接时，把堆上创建的 Connection* 指针塞进了 ev.data.ptr 注册到 epoll 中。但在后续状态机修改写事件（Mod）的代码里，手误写下了：
cpp
struct epoll_event ev;
ev.events = EPOLLIN | EPOLLOUT | EPOLLET;
ev.data.fd = fd; // <--- 致命改动！手误写成了存入整型 fd！
epoll_ctl(_epfd, EPOLL_CTL_MOD, fd, &ev);结果只要一发生写事件，主事件循环中执行：
cpp
Connection* conn = static_cast<Connection*>(_revents_ptr[i].data.ptr);
conn->_write_cb(conn); // 瞬间触发 Segmentation fault 崩溃！底层推导剖析：
查看 Linux 内核中 struct epoll_event 的定义：
c
typedef union epoll_data {
void *ptr;
int fd;
uint32_t u32;
uint64_t u64;
} epoll_data_t;
struct epoll_event {
uint32_t events; // 32 位事件掩码
epoll_data_t data; // 64 位数据联合体（Union）！
};在 64 位操作系统中，union epoll_data 的总大小只有 8 个字节，ptr 和 fd 在物理内存上是完全共享、重叠的同一块空间！
text
内存地址空间 (8 字节):
[ 0x00 ] [ 0x00 ] [ 0x00 ] [ 0x00 ] [ 0x00 ] [ 0x00 ] [ 0x00 ] [ 0x00 ]
|◄─────────────── 完整 64 位指针变量 ptr (指向堆上的 Connection) ──────────────►|
当你手误执行 ev.data.fd = 3 之后：
[ 0x03 ] [ 0x00 ] [ 0x00 ] [ 0x00 ] [ 0x?? ] [ 0x?? ] [ 0x?? ] [ 0x?? ]
|◄── 32 位 int fd ──►| (原本合法的 64 位指针高位或低位被强行碾压成废铁！)当你下一次把这块内存当成 Connection* ptr 取出时，指针的值变成了 0x0000000000000003。CPU 试图去解引用 0x3 这个操作系统保留的底层受保护地址，当场引发不可恢复的内核段错误异常！
防御铁律：
确立"万物皆指针"原则。在封装多路复用类时，底层 Add 和 Mod 接口严禁接收裸整型，彻底向用户态隐藏 data.fd，所有节点终生只存 Connection*。
2. 深坑二：同批次事件"先死后用"引发的 UAF（Use-After-Free）野指针
案发现场：
当客户端突然拔网线或强杀进程时，Linux 内核会向服务端发送 RST 或 FIN 包。此时在同一次 epoll_wait 唤醒中，内核可能会同时置位读和写标志位 （即 cur_events == (EPOLLIN | EPOLLOUT)）。
看最初的分发逻辑：
cpp
// 致命的隐患代码：
if (cur_events & EPOLLIN) {
conn->_read_cb(conn); // 读到 0 (对端关闭) -> 内部调用 ExceptHandler -> 执行了 delete conn！
}
if (cur_events & EPOLLOUT) {
conn->_write_cb(conn); // <--- 致命！conn 刚刚被 delete 释放，这里正在解引用野指针！
}底层推导剖析：
- 第一步执行
_read_cb(conn)，内部检测到对端断开，立刻调用ExceptHandler(conn)释放资源：
cpp
close(client_fd);
delete conn; // 堆内存已经被操作系统回收！此时 conn 指针变成了野指针！- 此时 CPU 根本不知道
conn已经死了，它紧接着顺理成章地进入下一个if (cur_events & EPOLLOUT)； SendHandler试图读取conn->_outbuffer，直接发生释放后使用（Use-After-Free），服务端在高并发下毫无征兆地瞬时段错误挂掉。
防御铁律：
主事件循环分发时，异常必须优先收口且必须带上阻断机制：
cpp
// 1. 优先捕获异常事件
if ((cur_events & (EPOLLERR | EPOLLHUP)) && conn->_except_cb) {
conn->_except_cb(conn);
continue; // 【核心阻断】：本轮该连接后续所有读写动作作废，直接跳过！
}同时在读写逻辑遇到底层物理错误时，一旦触发销毁，必须立即 return，绝不给后续逻辑执行的机会。
3. 深坑三：回调装配张冠李戴引发的"幽灵死锁"
案发现场：
在 AcceptHandler 中为新接入的客户端装填锦囊时，手误写下了：
cpp
Connection* client_conn = new Connection(client_fd);
client_conn->RegisterCallBack(
std::bind(&EpollServer::AcceptHandler, this, std::placeholders::_1), // <--- 手误绑成了 AcceptHandler！
std::bind(&EpollServer::SendHandler, this, std::placeholders::_1),
std::bind(&EpollServer::ExceptHandler, this, std::placeholders::_1)
);症状推导：
客户端成功建立了 TCP 三次握手，并且在控制台敲入字符按下回车发送；
服务端的 epoll_wait 也确实灵敏地返回了该套接字的可读事件；
但是客户端永远收不到回音，服务端既不报错也不打印，仿佛数据凭空消失在以太网中！
原因拆解：
新客户端发来数据触发了读就绪，Reactor 引擎老老实实执行绑在它身上的 _read_cb，结果调用的却是 AcceptHandler。AcceptHandler 内部去对 _listen_fd 调 accept，由于此刻根本没有新的新连接建立，accept 瞬间返回 EAGAIN 退出。
客户端发送的数据自始至终没有被任何代码 read 出来，永远堆积在操作系统内核队列中！
4. 深坑四：非阻塞 ET 下的"伪写完成"与数据截断
案发现场：
在 SendHandler 中，很多同学喜欢写：
cpp
ssize_t s = write(client_fd, conn->_outbuffer.c_str(), conn->_outbuffer.size());
if (s > 0) {
conn->_outbuffer.clear(); // 以为一次 write 就能把所有数据全部发完！
}灾难推导：
如果上层业务产生了一个 1MB 大小的大包（比如一张图片或大 JSON），而此时内核发送缓冲区只剩 64KB 的空位。
调用 write 只会返回 65536（实际写入字节数）。如果你直接盲目地 clear()，剩下的 900 多 KB 数据直接被丢弃丢失，导致客户端收到损坏被截断的乱码，造成严重的数据损坏事故。
正确做法：
必须使用 conn->_outbuffer.erase(0, s)，发掉多少从缓冲区抹除多少，并且必须在 while 循环中持续冲刷，直到返回 EAGAIN！
第四章：架构进阶------业务层与网络层的彻底解耦
一个优秀的基础架构，必须让网络 I/O 归网络，业务逻辑归业务。
我们在 EpollServer 中引入业务回调类型：
cpp
using BusinessHandler = std::function<std::string(const std::string&)>;整体数据流动拓扑图：
text
[ 客户端网络流 ]
│
▼ (ET 非阻塞循环抽干)
conn->_inbuffer
│
▼ (ParseMessage 定界符切割)
提取出纯净的完整报文 msg
│
▼ (抛给业务回调，网络层不参与具体计算)
std::string resp = _business_cb(msg);
│
▼ (追加协议定界符 '\n')
推入 conn->_outbuffer
│
▼ (输出状态机)
SendHandler(conn) ──► 发送给对端这样一来，网络底层框架被彻底冻结，无论是实现回声测试、英汉字典、大写转换还是复杂的 RPC 调用，只需要在 main.cpp 中像换插头一样注入不同的函数即可！
第五章：完整工业级源码落地
工程采用模块化结构，分为：
-
Connection.hpp：连接与回调容器； -
Epoll.hpp：纯粹的系统调用封装； -
EpollServer.hpp/.cpp：Reactor 核心分发与状态机驱动； -
main.cpp：业务组装与入口。
1. 会话容器与回调定义：Connection.hpp
cpp
#pragma once
#include <string>
#include <functional>
struct Connection;
// 统一标准回调签名：将本连接自身指针传回，便于内部自省操作
using Callback = std::function<void(Connection*)>;
struct Connection {
int _sock_fd;
std::string _inbuffer; // 专属数据接收输入仓
std::string _outbuffer; // 专属数据发送输出仓
// 三大专属事件回调锦囊
Callback _read_cb;
Callback _write_cb;
Callback _except_cb;
explicit Connection(int fd)
: _sock_fd(fd),
_read_cb(nullptr),
_write_cb(nullptr),
_except_cb(nullptr) {}
// 一次性注册/更新回调锦囊
void RegisterCallBack(Callback r, Callback w, Callback e) {
_read_cb = r;
_write_cb = w;
_except_cb = e;
}
};2. 系统调用封装：Epoll.hpp
cpp
#pragma once
#include <iostream>
#include <cstdlib>
#include <sys/epoll.h>
#include <unistd.h>
class Epoll {
public:
explicit Epoll(int size = 128) {
_epfd = epoll_create(size);
if (_epfd < 0) {
perror("epoll_create 出错");
exit(1);
}
}
~Epoll() {
if (_epfd >= 0) {
close(_epfd);
}
}
// 严禁接受裸 int 作为 data，彻底消灭联合体内存覆盖风险
bool Add(int fd, uint32_t events, void* ptr) {
struct epoll_event ev;
ev.events = events;
ev.data.ptr = ptr;
return epoll_ctl(_epfd, EPOLL_CTL_ADD, fd, &ev) == 0;
}
bool Mod(int fd, uint32_t events, void* ptr) {
struct epoll_event ev;
ev.events = events;
ev.data.ptr = ptr;
return epoll_ctl(_epfd, EPOLL_CTL_MOD, fd, &ev) == 0;
}
bool Del(int fd) {
return epoll_ctl(_epfd, EPOLL_CTL_DEL, fd, nullptr) == 0;
}
int Wait(struct epoll_event* events, int maxevents, int timeout) {
return epoll_wait(_epfd, events, maxevents, timeout);
}
private:
int _epfd;
};3. Reactor 核心引擎接口：EpollServer.hpp
cpp
#pragma once
#include <iostream>
#include <string>
#include <memory>
#include <functional>
#include <sys/epoll.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <fcntl.h>
#include <unistd.h>
#include "Epoll.hpp"
#include "Connection.hpp"
// 业务处理函数签名：纯粹的请求字符串进，纯粹的响应字符串出
using BusinessHandler = std::function<std::string(const std::string&)>;
class EpollServer {
public:
EpollServer(uint16_t port, BusinessHandler business_cb, int max_events = 64);
~EpollServer();
void Init();
void Start();
// 核心事件分发处理方法（全部符合 Callback 签名规格）
void AcceptHandler(Connection* conn);
void RecvHandler(Connection* conn);
void SendHandler(Connection* conn);
void ExceptHandler(Connection* conn);
private:
int CreateListenSocket(uint16_t port);
void SetNonBlock(int fd);
bool ParseMessage(std::string& inbuffer, std::string* msg);
private:
uint16_t _port;
int _listen_fd;
int _max_events;
std::unique_ptr<Epoll> _epoll_ptr;
std::unique_ptr<struct epoll_event[]> _revents_ptr;
BusinessHandler _business_cb; // 上层业务处理回调
};4. Reactor 核心引擎实现：EpollServer.cpp
cpp
#include "EpollServer.hpp"
EpollServer::EpollServer(uint16_t port, BusinessHandler business_cb, int max_events)
: _port(port),
_listen_fd(-1),
_max_events(max_events),
_epoll_ptr(nullptr),
_revents_ptr(nullptr),
_business_cb(business_cb) {}
EpollServer::~EpollServer() {
if (_listen_fd >= 0) {
close(_listen_fd);
}
}
void EpollServer::SetNonBlock(int fd) {
int fl = fcntl(fd, F_GETFL);
if (fl < 0) return;
fcntl(fd, F_SETFL, fl | O_NONBLOCK);
}
int EpollServer::CreateListenSocket(uint16_t port) {
int sock = socket(AF_INET, SOCK_STREAM, 0);
if (sock < 0) return -1;
int opt = 1;
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
struct sockaddr_in local;
local.sin_family = AF_INET;
local.sin_port = htons(port);
local.sin_addr.s_addr = INADDR_ANY;
if (bind(sock, (struct sockaddr*)&local, sizeof(local)) < 0) {
close(sock);
return -1;
}
if (listen(sock, 128) < 0) {
close(sock);
return -1;
}
return sock;
}
// 协议解析器：根据定界符 '\n' 抽取完整报文，解决 TCP 粘包/半包
bool EpollServer::ParseMessage(std::string& inbuffer, std::string* msg) {
auto pos = inbuffer.find('\n');
if (pos == std::string::npos) {
return false; // 尚无完整报文，继续驻留在 inbuffer
}
*msg = inbuffer.substr(0, pos);
inbuffer.erase(0, pos + 1); // 抹除已被消费的报文连同定界符
return true;
}
void EpollServer::Init() {
_listen_fd = CreateListenSocket(_port);
if (_listen_fd < 0) {
std::cerr << "创建监听套接字失败，端口: " << _port << std::endl;
exit(1);
}
SetNonBlock(_listen_fd);
_epoll_ptr = std::make_unique<Epoll>(128);
_revents_ptr = std::make_unique<struct epoll_event[]>(_max_events);
// 1. 万物皆 Connection：为监听套接字创建会话容器
Connection* listen_conn = new Connection(_listen_fd);
// 2. 装填监听专属读锦囊（AcceptHandler）
listen_conn->RegisterCallBack(
std::bind(&EpollServer::AcceptHandler, this, std::placeholders::_1),
nullptr,
nullptr
);
// 3. 挂载至 epoll 树
if (!_epoll_ptr->Add(_listen_fd, EPOLLIN | EPOLLET, listen_conn)) {
std::cerr << "挂载 listen_fd 失败" << std::endl;
delete listen_conn;
exit(1);
}
std::cout << "Reactor 反应堆初始化完成，监听端口: " << _port << std::endl;
}
void EpollServer::Start() {
std::cout << "Reactor 引擎启动，纯事件驱动调度开始运行..." << std::endl;
while (true) {
int nready = _epoll_ptr->Wait(_revents_ptr.get(), _max_events, 3000);
if (nready < 0) {
if (errno == EINTR) continue; // 信号中断打断，重试
std::cerr << "epoll_wait 系统调用出错" << std::endl;
break;
} else if (nready == 0) {
continue; // 超时，继续轮询
}
// 核心调度循环：彻底消灭 if (fd == listen_fd) 类的硬编码！
for (int i = 0; i < nready; i++) {
Connection* conn = static_cast<Connection*>(_revents_ptr[i].data.ptr);
uint32_t cur_events = _revents_ptr[i].events;
// 1. 异常优先收口：严防同批次读写产生 UAF 野指针
if ((cur_events & (EPOLLERR | EPOLLHUP)) && conn->_except_cb) {
conn->_except_cb(conn);
continue; // 【阻断】：本连接已死，绝不执行后续分支！
}
// 2. 读就绪：无脑触发专属读锦囊
if ((cur_events & EPOLLIN) && conn->_read_cb) {
conn->_read_cb(conn);
}
// 3. 写就绪：无脑触发专属写锦囊
if ((cur_events & EPOLLOUT) && conn->_write_cb) {
conn->_write_cb(conn);
}
}
}
}
void EpollServer::AcceptHandler(Connection* conn) {
(void)conn;
// ET 模式必须非阻塞循环 accept 接收所有新连接
while (true) {
struct sockaddr_in peer;
socklen_t len = sizeof(peer);
int client_fd = accept(_listen_fd, (struct sockaddr*)&peer, &len);
if (client_fd < 0) {
if (errno == EAGAIN || errno == EWOULDBLOCK) break; // 本轮全量新连接已接完
if (errno == EINTR) continue;
std::cerr << "accept 调用出错" << std::endl;
break;
}
SetNonBlock(client_fd);
Connection* client_conn = new Connection(client_fd);
// 为客户端装配三大完整锦囊（注意：读锦囊必须绑定 RecvHandler！）
client_conn->RegisterCallBack(
std::bind(&EpollServer::RecvHandler, this, std::placeholders::_1),
std::bind(&EpollServer::SendHandler, this, std::placeholders::_1),
std::bind(&EpollServer::ExceptHandler, this, std::placeholders::_1)
);
if (!_epoll_ptr->Add(client_fd, EPOLLIN | EPOLLET, client_conn)) {
std::cerr << "挂载新客户端失败" << std::endl;
ExceptHandler(client_conn);
continue;
}
std::cout << "[fd: " << client_fd << "] 新客户端挂载并绑定三大回调完成" << std::endl;
}
}
void EpollServer::RecvHandler(Connection* conn) {
char buf[1024];
int client_fd = conn->_sock_fd;
// ET 模式必须循环读取直到返回 EAGAIN
while (true) {
ssize_t s = read(client_fd, buf, sizeof(buf) - 1);
if (s > 0) {
buf[s] = 0;
conn->_inbuffer += buf; // 追加至专属输入仓
} else if (s == 0) {
std::cout << "[fd: " << client_fd << "] 客户端主动断开连接" << std::endl;
ExceptHandler(conn);
return;
} else {
if (errno == EAGAIN || errno == EWOULDBLOCK) break; // 数据已彻底读干
if (errno == EINTR) continue;
std::cerr << "read 调用出错" << std::endl;
ExceptHandler(conn);
return;
}
}
// 协议切包与业务派发
std::string msg;
while (ParseMessage(conn->_inbuffer, &msg)) {
std::cout << "[fd: " << client_fd << "] 提取出完整业务请求: [" << msg << "]" << std::endl;
// 调用解耦的业务逻辑
std::string response;
if (_business_cb) {
response = _business_cb(msg);
} else {
response = msg;
}
response += "\n"; // 包装协议定界符
// 推入专属输出仓，并尝试直接发送
conn->_outbuffer += response;
SendHandler(conn);
}
}
void EpollServer::SendHandler(Connection* conn) {
int client_fd = conn->_sock_fd;
// 非阻塞循环冲刷输出仓
while (!conn->_outbuffer.empty()) {
ssize_t s = write(client_fd, conn->_outbuffer.c_str(), conn->_outbuffer.size());
if (s > 0) {
conn->_outbuffer.erase(0, s); // 抹除已成功刷入内核的字节
} else {
if (errno == EAGAIN || errno == EWOULDBLOCK) break; // 内核写缓冲打满
if (errno == EINTR) continue;
std::cerr << "write 调用出错" << std::endl;
ExceptHandler(conn);
return;
}
}
// 严密的状态机收敛：按需决定是否关心 EPOLLOUT
if (!conn->_outbuffer.empty()) {
// 缓冲区有残余，开启 EPOLLOUT 托管，等待内核通知[cite: 1]
_epoll_ptr->Mod(client_fd, EPOLLIN | EPOLLOUT | EPOLLET, conn);
} else {
// 缓冲区已全空，关闭 EPOLLOUT，彻底杜绝 CPU 100% 空转[cite: 1]
_epoll_ptr->Mod(client_fd, EPOLLIN | EPOLLET, conn);
}
}
void EpollServer::ExceptHandler(Connection* conn) {
int client_fd = conn->_sock_fd;
_epoll_ptr->Del(client_fd); // 1. 从 epoll 红黑树彻底摘除[cite: 1]
close(client_fd); // 2. 关闭底层套接字句柄[cite: 1]
delete conn; // 3. 回收堆上创建的 Connection 实例[cite: 1]
std::cout << "[fd: " << client_fd << "] 资源已统一且安全地释放注销" << std::endl;
}5. 业务解耦驱动层：main.cpp
cpp
#include <iostream>
#include <string>
#include <algorithm>
#include "EpollServer.hpp"
// 业务插件 1：将客户端输入转换为大写返回
std::string ToUpperService(const std::string& req) {
std::string resp = req;
for (char& c : resp) {
c = std::toupper(c);
}
return "[ToUpper] " + resp;
}
// 业务插件 2：回显服务
std::string EchoService(const std::string& req) {
return "[Echo] " + req;
}
int main(int argc, char* argv[]) {
if (argc != 2) {
std::cerr << "Usage: " << argv[0] << " <port>" << std::endl;
return 1;
}
uint16_t port = static_cast<uint16_t>(std::stoi(argv[1]));
// 核心网络引擎完全作为通用底座，业务函数可任意插拔！
EpollServer server(port, ToUpperService);
server.Init();
server.Start();
return 0;
}本章高频面试题与深度解析
面试题 1：在 Reactor 反应堆模型中，为什么通常要为每一个 TCP 连接绑定独立的 inbuffer 和 outbuffer，而不是使用线程级共享的全局缓冲区？
深度解析
- 核心考察点：考察候选人对 TCP 流式特性、非阻塞 I/O 以及并发会话独立性的物理理解。
- 原理解析：
-
应对流式传输的截断与粘包 ：网络底层的数据传输是碎片化的，当单个请求被分割在不同的 TCP 分节到达时，若使用共享缓冲区，后续其他连接的数据会将其覆盖损坏。独立的
inbuffer实现了连接会话维度的上下文长期持久化，保障了报文拼接的正确性； -
非阻塞发送的背压机制（Backpressure） ：当网络拥塞、内核发送缓冲区打满导致
write返回EAGAIN时，未发送完毕的数据必须妥善暂存在应用层的outbuffer中。若没有专属outbuffer，数据就会在多次事件调度之间丢失，无法实现断点续传。
标准答案
- 隔离流式数据生命周期 ：TCP 是面向字节流的协议，半包和粘包是常态。独立
inbuffer能在多次非阻塞读取之间安全保留未拼装完毕的请求数据，防止跨连接的数据污染；- 支撑非阻塞按需发送 ：当写缓冲区满导致发送中断时，独立的
outbuffer能缓冲剩余数据，配合EPOLLOUT事件完成渐进式的排空发送，保证了应用层数据的完整性与并发安全性。
面试题 2：为什么说 Reactor 模式天然具备向多进程 / 多线程（One Thread One Loop，OTOL）架构无缝演进的能力？
深度解析
-
核心考察点：考察候选人对现代工业级服务器架构（如 Nginx、Netty、Muduo）扩展模式的宏观把控能力。
-
原理解析 ：
单 Reactor 模型的核心是将"事件监听"、"回调触发"与"会话管理"封装成闭环。
当需要横向扩展以利用多核 CPU 时：
-
主从 Reactor 模型（Master-Slave Reactor）：
-
主 Reactor（Master 线程）仅负责监听
listen_fd并接受新连接； -
接受到客户端
client_fd后，通过管道（pipe）或轻量事件描述符（eventfd）将连接负载均衡地分派给多个子 Reactor（Worker 线程）； -
每个 Worker 线程拥有自己独立的
epoll实例和事件循环（即 One Thread One Loop），各子 Reactor 独立处理自己管辖连接的生命周期。
标准答案
生命周期高度内聚 ：单 Reactor 模型中连接（
Connection）的所有读写与异常行为全部闭环在自身的回调函数中，彼此完全独立无共享状态，具备天然的解耦特性；平滑的职责拆分 ：向 OTOL 演进时，主线程（MainReactor）只专注
accept接入新连接，工作线程（SubReactor）各自运行一个独立的事件循环处理 I/O 读写，无需对核心的 Reactor 调度逻辑进行颠覆性重构，扩展成本极低。