大白话Reactor模式

Reactor模式是高性能网络编程的核心设计模式，本质是"事件驱动+批量监控IO"，能让1个/少数几个线程高效处理成千上万个网络连接。本文用「餐厅运营」的生活例子类比，一步步拆解Reactor，再用简单的C++代码实现，确保小白也能看懂。

一、先搞懂：Reactor要解决什么问题？

先看传统网络编程的"坑"：

假设你写了一个TCP服务端，传统做法是一个客户端连接 = 一个线程（BIO模型）：

来了1000个客户端，就要创建1000个线程；
线程多了会导致CPU频繁切换线程（上下文切换），内存被占满，系统直接卡爆。

而Reactor模式的目标：用1个/几个线程，管所有客户端连接，只在连接"有事儿"时才处理（比如客户端发数据、要收数据），没事就歇着，不浪费资源。

生活类比：餐厅怎么服务顾客？

传统BIO：1个服务员盯1桌顾客，哪怕顾客只是玩手机没点餐，服务员也得站着等，100桌就要100个服务员，成本高、效率低；
Reactor模式：1个大堂经理（Reactor）盯着所有桌，顾客需要点餐/加菜/结账（事件）时，经理再喊对应的服务员（处理器）过去，服务员处理完就歇着，1个经理+几个服务员就能管100桌。

二、Reactor的核心思想（大白话）

反向干活：不是程序主动问"每个连接有没有数据？"（轮询），而是"连接有数据了主动告诉程序"（事件通知）；
批量监控：用操作系统提供的"批量监控工具"（epoll/select/poll），一次监控所有连接的状态，不用一个个问；
分工明确：专门有人（Reactor核心）负责"监控+喊人干活"，专门有人（事件处理器）负责"具体干活"（读数据、写数据）。

三、Reactor的核心组件（角色对应）

用「餐厅」角色对应技术组件，一眼看懂：

Reactor组件	餐厅角色	核心作用
事件源（Event Source）	顾客/餐桌	产生"事件"的对象（对应网络编程里的socket连接/文件描述符FD），比如： ✅ 顾客点餐 = 客户端发数据（读事件） ✅ 顾客要上菜 = 客户端收数据（写事件） ✅ 新顾客进门 = 新连接事件
多路分发器（Multiplexer）	经理的"观察面板"	操作系统提供的批量监控工具（Linux用epoll，Windows用IOCP），能一次性看到所有"餐桌"的状态（哪个桌有事件）
事件处理器（EventHandler）	服务员（手册）	所有"服务员"的统一操作手册（接口），规定"处理点餐/上菜/结账"的统一动作
具体事件处理器	迎宾员/点餐员	实现"操作手册"的具体人： ✅ 迎宾员（Acceptor）：专门处理"新顾客进门" ✅ 点餐员（Connection）：专门处理"点餐/上菜"
Reactor核心	大堂经理	总协调： 1. 把"餐桌/迎宾位"加到观察面板（注册事件） 2. 盯着面板等事件 3. 事件来了喊对应服务员处理

四、Reactor的工作流程（一步一步走）

还是用「餐厅」流程对应技术流程，新手也能跟得上：

步骤1：餐厅开业（初始化）

大堂经理（Reactor）准备好"观察面板"（调用epoll_create创建epoll句柄）；
门口设"迎宾位"（创建监听socket，绑定端口+监听）；
经理把"迎宾位"加到观察面板，指定关注"有新顾客进门"（注册监听FD的读事件）；
给迎宾位绑定"迎宾员"（Acceptor），专门处理新顾客。

步骤2：经理盯面板（事件循环）

经理一直盯着观察面板，啥也不干，就等有事件发生（调用epoll_wait阻塞等待）。

步骤3：新顾客进门（处理连接事件）

观察面板显示"迎宾位有新顾客"（epoll返回监听FD的读事件）；
经理喊迎宾员（Acceptor）过去：
- 迎宾员接顾客进门（调用accept接受新连接）；
- 给顾客安排餐桌（创建客户端socket FD）；
- 经理把"餐桌"加到观察面板，指定关注"顾客点餐"（注册客户端FD的读事件）；
- 给餐桌绑定"点餐员"（Connection），专门服务这桌顾客。

步骤4：顾客点餐（处理读事件）

观察面板显示"某餐桌要点餐"（epoll返回客户端FD的读事件）；
经理喊对应点餐员（Connection）过去：
- 点餐员记录顾客点的菜（调用read读取客户端数据）；
- 若需要上菜，经理把这桌的"上菜"事件加到面板（修改事件为写事件）。

步骤5：给顾客上菜（处理写事件）

观察面板显示"某餐桌要上菜"（epoll返回客户端FD的写事件）；
经理喊点餐员过去上菜（调用write给客户端发响应数据）；
上完菜，经理把这桌的事件改回"点餐"（关注读事件），等顾客下次点餐。

步骤6：循环往复

经理回到步骤2，继续盯着面板，处理下一波事件。

五、C++实现Reactor（极简版，注释拉满）

我们用Linux的epoll实现一个"回显服务端"（客户端发啥，服务端就回啥），代码拆成5个部分，每部分都解释清楚。

环境说明

系统：Linux（epoll是Linux专属，跨平台可用select/poll）；
编译：g++ -std=c++11 reactor_demo.cpp -o reactor_demo；
测试：用nc 127.0.0.1 8888连接，输入文字就能看到回显。

第一步：写"服务员操作手册"（EventHandler接口）

所有"服务员"都要遵守的规则，规定统一的操作（比如"处理事件"）：

cpp 复制代码

#include <sys/epoll.h>   // epoll相关函数
#include <sys/socket.h>  // socket相关
#include <netinet/in.h>  // 网络地址结构
#include <unistd.h>      // close、read、write
#include <fcntl.h>       // 设置非阻塞
#include <iostream>      // 打印日志
#include <unordered_map> // FD和处理器的映射
#include <string>        // 字符串处理

// 事件类型（大白话版，对应epoll的宏）
enum EventType {
    READ_EVENT = EPOLLIN,   // 读事件（顾客点餐）
    WRITE_EVENT = EPOLLOUT, // 写事件（给顾客上菜）
    ERROR_EVENT = EPOLLERR  // 错误事件（餐桌出问题）
};

// 事件处理器接口（服务员操作手册）
class EventHandler {
public:
    // 虚析构：确保子类能正确释放
    virtual ~EventHandler() = default;

    // 获取绑定的FD（对应"餐桌号/迎宾位号"）
    virtual int get_fd() const = 0;

    // 处理事件（核心：点餐/上菜/处理错误）
    virtual void handle_event(int events) = 0;
};

第二步：写"大堂经理"（Reactor核心类）

负责"管理观察面板、监控事件、喊服务员干活"：

cpp 复制代码

// Reactor核心（大堂经理）
class Reactor {
public:
    Reactor() {
        // 1. 创建epoll"观察面板"（EPOLL_CLOEXEC：进程退出自动关闭）
        epoll_fd_ = epoll_create1(EPOLL_CLOEXEC);
        if (epoll_fd_ < 0) {
            perror("创建epoll面板失败"); // 打印错误原因
            exit(1); // 退出程序
        }
    }

    ~Reactor() {
        // 关闭观察面板
        if (epoll_fd_ >= 0) close(epoll_fd_);
    }

    // 注册事件（把餐桌/迎宾位加到观察面板）
    bool add_event(EventHandler* handler, int events) {
        int fd = handler->get_fd();
        struct epoll_event ev;
        ev.data.ptr = handler; // 关键：把服务员绑定到事件，方便后续喊人
        ev.events = events | EPOLLET; // EPOLLET：边缘触发（只通知一次，效率高）

        // 把FD和事件加到epoll面板
        if (epoll_ctl(epoll_fd_, EPOLL_CTL_ADD, fd, &ev) < 0) {
            perror("添加事件失败");
            return false;
        }
        fd_to_handler_[fd] = handler; // 记录"餐桌号-服务员"映射
        return true;
    }

    // 修改事件（比如从"点餐"改成"上菜"）
    bool mod_event(EventHandler* handler, int events) {
        int fd = handler->get_fd();
        struct epoll_event ev;
        ev.data.ptr = handler;
        ev.events = events | EPOLLET;

        if (epoll_ctl(epoll_fd_, EPOLL_CTL_MOD, fd, &ev) < 0) {
            perror("修改事件失败");
            return false;
        }
        return true;
    }

    // 移除事件（顾客走了，把餐桌从面板删掉）
    bool del_event(EventHandler* handler) {
        int fd = handler->get_fd();
        if (epoll_ctl(epoll_fd_, EPOLL_CTL_DEL, fd, nullptr) < 0) {
            perror("移除事件失败");
            return false;
        }
        fd_to_handler_.erase(fd); // 删掉"餐桌号-服务员"映射
        return true;
    }

    // 事件循环（经理盯着面板等事件）
    void run() {
        struct epoll_event ready_events[1024]; // 最多一次处理1024个事件

        while (true) { // 无限循环，一直监控
            // 等待事件（-1：一直等，直到有事件）
            int n = epoll_wait(epoll_fd_, ready_events, 1024, -1);
            if (n < 0) {
                perror("等待事件失败");
                continue; // 出错了也不退出，继续等
            }

            // 遍历所有就绪事件，喊对应服务员干活
            for (int i = 0; i < n; i++) {
                EventHandler* handler = (EventHandler*)ready_events[i].data.ptr;
                if (handler) handler->handle_event(ready_events[i].events);
            }
        }
    }

private:
    int epoll_fd_; // epoll面板的FD
    std::unordered_map<int, EventHandler*> fd_to_handler_; // 餐桌号→服务员
};

第三步：写"迎宾员"（Acceptor）

专门处理"新顾客进门"（监听FD的读事件）：

cpp 复制代码

// Acceptor（迎宾员）：处理新连接
class Acceptor : public EventHandler {
public:
    Acceptor(int listen_fd, Reactor* reactor) 
        : listen_fd_(listen_fd), reactor_(reactor) {}

    // 获取迎宾位FD
    int get_fd() const override { return listen_fd_; }

    // 处理新顾客进门事件
    void handle_event(int events) override {
        if (events & READ_EVENT) { // 有新顾客进门
            struct sockaddr_in client_addr; // 顾客地址
            socklen_t addr_len = sizeof(client_addr);

            // 接受新连接（SOCK_NONBLOCK：非阻塞，避免卡住）
            int client_fd = accept4(listen_fd_, (struct sockaddr*)&client_addr, 
                                   &addr_len, SOCK_NONBLOCK | SOCK_CLOEXEC);
            if (client_fd < 0) {
                perror("接顾客失败");
                return;
            }

            // 打印顾客信息（IP+端口）
            char ip[32];
            inet_ntop(AF_INET, &client_addr.sin_addr, ip, sizeof(ip));
            std::cout << "新顾客：" << ip << ":" << ntohs(client_addr.sin_port) 
                      << "，餐桌号：" << client_fd << std::endl;

            // 创建点餐员，绑定到新餐桌，注册"点餐事件"
            EventHandler* conn = new Connection(client_fd, reactor_);
            reactor_->add_event(conn, READ_EVENT);
        }
    }

private:
    int listen_fd_; // 迎宾位FD（监听socket）
    Reactor* reactor_; // 大堂经理
};

第四步：写"点餐员"（Connection）

处理顾客的"点餐（读数据）"和"上菜（写数据）"：

cpp 复制代码

// Connection（点餐员）：处理顾客的读写事件
class Connection : public EventHandler {
public:
    Connection(int client_fd, Reactor* reactor) 
        : client_fd_(client_fd), reactor_(reactor) {}

    ~Connection() {
        // 顾客走了，关掉餐桌
        if (client_fd_ >= 0) {
            std::cout << "顾客离开，餐桌号：" << client_fd_ << std::endl;
            close(client_fd_);
        }
    }

    // 获取餐桌FD
    int get_fd() const override { return client_fd_; }

    // 处理事件（点餐/上菜/错误）
    void handle_event(int events) override {
        if (events & ERROR_EVENT) { // 餐桌出问题
            handle_error();
        } else if (events & READ_EVENT) { // 顾客点餐
            handle_read();
        } else if (events & WRITE_EVENT) { // 给顾客上菜
            handle_write();
        }
    }

private:
    // 处理点餐（读数据）
    void handle_read() {
        char buf[1024] = {0}; // 点餐本
        ssize_t n = read(client_fd_, buf, sizeof(buf)-1); // 读顾客点的菜

        if (n < 0) { // 读失败
            perror("读数据失败");
            delete this; // 点餐员下班（释放自己）
            return;
        }
        if (n == 0) { // 顾客走了（关闭连接）
            delete this;
            return;
        }

        // 保存顾客点的菜，准备上菜
        recv_data_ = std::string(buf, n);
        std::cout << "餐桌" << client_fd_ << "点餐：" << recv_data_ << std::endl;

        // 告诉经理：这桌要上菜（修改事件为写事件）
        reactor_->mod_event(this, WRITE_EVENT);
    }

    // 处理上菜（写数据）
    void handle_write() {
        // 给顾客上菜（写数据）
        ssize_t n = write(client_fd_, recv_data_.c_str(), recv_data_.size());
        if (n < 0) {
            perror("写数据失败");
            delete this;
            return;
        }

        std::cout << "餐桌" << client_fd_ << "上菜：" << recv_data_ << std::endl;

        // 上完菜，改回"点餐事件"，等顾客下次点餐
        reactor_->mod_event(this, READ_EVENT);
        recv_data_.clear(); // 清空点餐本
    }

    // 处理错误
    void handle_error() {
        std::cerr << "餐桌" << client_fd_ << "出问题了" << std::endl;
        delete this;
    }

private:
    int client_fd_; // 顾客餐桌FD
    Reactor* reactor_; // 大堂经理
    std::string recv_data_; // 顾客点的菜（接收缓冲区）
};

第五步：辅助函数+主函数（餐厅开业）

创建"迎宾位"（监听socket），启动经理和服务员：

cpp 复制代码

// 创建监听socket（迎宾位）
int create_listen_fd(int port) {
    // 1. 创建迎宾位（SOCK_NONBLOCK：非阻塞，避免卡住）
    int listen_fd = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK | SOCK_CLOEXEC, 0);
    if (listen_fd < 0) {
        perror("创建迎宾位失败");
        exit(1);
    }

    // 2. 允许端口复用（重启服务不报错）
    int opt = 1;
    setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT, &opt, sizeof(opt));

    // 3. 绑定端口（比如8888）
    struct sockaddr_in server_addr;
    server_addr.sin_family = AF_INET;
    server_addr.sin_addr.s_addr = INADDR_ANY; // 监听所有网卡
    server_addr.sin_port = htons(port); // 端口转网络字节序
    if (bind(listen_fd, (struct sockaddr*)&server_addr, sizeof(server_addr)) < 0) {
        perror("绑定端口失败");
        close(listen_fd);
        exit(1);
    }

    // 4. 开始监听（最多排队1024个顾客）
    if (listen(listen_fd, 1024) < 0) {
        perror("监听失败");
        close(listen_fd);
        exit(1);
    }

    return listen_fd;
}

// 主函数（餐厅开业）
int main() {
    const int PORT = 8888; // 迎宾位端口

    // 1. 创建迎宾位（监听socket）
    int listen_fd = create_listen_fd(PORT);
    std::cout << "餐厅开业！迎宾位端口：" << PORT << "，编号：" << listen_fd << std::endl;

    // 2. 雇大堂经理（Reactor）
    Reactor reactor;

    // 3. 雇迎宾员，绑定到迎宾位，加到经理的观察面板
    Acceptor acceptor(listen_fd, &reactor);
    reactor.add_event(&acceptor, READ_EVENT);

    // 4. 经理开始上班（启动事件循环）
    reactor.run();

    return 0;
}

六、运行验证（手把手教）

1. 编译代码

把上面所有代码复制到reactor_demo.cpp文件，执行：

bash 复制代码

g++ -std=c++11 reactor_demo.cpp -o reactor_demo

2. 启动服务端

bash 复制代码

./reactor_demo

看到输出：餐厅开业！迎宾位端口：8888，编号：3（编号可能不同）。

3. 测试客户端

打开新终端，输入：

bash 复制代码

nc 127.0.0.1 8888

然后输入任意文字（比如hello reactor），回车后会看到服务端回显同样的文字。

4. 服务端日志示例

复制代码

餐厅开业！迎宾位端口：8888，编号：3
新顾客：127.0.0.1:56789，餐桌号：4
餐桌4点餐：hello reactor
餐桌4上菜：hello reactor

七、关键注意事项（避坑指南）

1. 为什么要用"非阻塞IO"？

如果餐桌（FD）是阻塞的，点餐员（read/write）可能卡在某桌，导致其他桌没人管。非阻塞就是"这桌暂时没数据，先去管别的桌"，不耽误事。

2. 边缘触发（EPOLLET）是什么？

水平触发（默认）：只要桌有事件（比如没读完的数据），经理会一直喊服务员；
边缘触发：只喊一次，服务员必须把事干完（比如把数据读完），效率更高（少喊人）。
✅ 用EPOLLET必须配合非阻塞IO，否则可能漏处理事件。

3. 内存会不会泄漏？

示例中Connection（点餐员）在"顾客走了/出错"时会delete this（自己释放），避免内存泄漏；实际项目中可以用智能指针（std::unique_ptr）更安全。

4. 单Reactor不够用怎么办？

上面是"单经理+单线程"，如果顾客太多/点餐处理慢（比如要查数据库），会卡住经理。优化方案是主从Reactor：

主经理：只管迎宾，接完顾客分给多个"副经理"；
副经理：每个副经理管一部分餐桌，并行干活，利用多核CPU。

八、总结

Reactor模式的核心就3句话：

用epoll/select批量监控所有连接（经理盯面板）；
连接有事件才处理（顾客有需求才喊服务员）；
分工明确（迎宾管接客，点餐员管服务）。

C++实现的关键是：

定义统一的EventHandler接口（服务员手册）；
封装Reactor核心（经理），处理epoll的增删改查；
实现Acceptor（迎宾）和Connection（点餐员），处理具体事件。

实际项目中不用自己写全套（有成熟库如muduo、Asio），但理解这个模式，就能看懂Redis、Nginx这些高性能软件的底层逻辑了。

Reactor模式（C++）核心应用场景 + 5道高价值面试题（中等难度）

一、Reactor模式在C++中的核心应用场景

Reactor模式是C++高性能网络编程的"标配"，其核心价值是用少量线程高效处理海量并发IO连接，以下是最典型的落地场景，均贴合C++的语言特性（零开销抽象、内存可控、系统调用直接性）：

应用场景	业务特点	Reactor模式的核心价值	C++技术优势
高性能HTTP/反向代理服务器（如Nginx）	数万级并发连接、低延迟、高吞吐	单/主从Reactor+epoll批量监控连接，仅处理就绪事件	零开销抽象、直接调用epoll、内存手动管理（无GC）
游戏服务器（网关/逻辑服）	数千~数万玩家长连接、实时消息（战斗/移动）	主从Reactor隔离IO线程与业务线程，避免逻辑阻塞IO	多线程控制（std::thread）、内存池减少分配开销
金融低延迟交易系统	微秒级延迟、高频交易指令、连接数适中	单Reactor+EPOLLET+非阻塞IO，减少系统调用次数	禁用RTTI/异常、CPU亲和性绑定、裸内存操作
IoT网关服务器	数万设备长连接、低频率数据上报/心跳	批量监控设备连接，仅在有数据时处理，节省资源	轻量级（无GC）、适配嵌入式Linux
分布式存储通信层（Ceph）	节点间海量RPC通信、高可靠异步交互	Reactor+Protobuf解析，处理异步通信事件	面向对象抽象（EventHandler）、灵活的协议扩展

二、5道中等难度面试题

题目1：主从Reactor架构设计与C++实现

题目描述

单Reactor单线程模型在"高并发+10ms级耗时业务逻辑"场景下性能瓶颈显著，请完成：

分析单Reactor单线程的核心性能瓶颈；
设计"主从Reactor"架构解决该问题，画出核心架构图并说明各组件职责；
用C++伪代码实现"主Reactor接受连接并分发到从Reactor"的核心逻辑（需考虑线程安全）。

考察点

Reactor核心架构理解；
C++多线程（std::thread/mutex）的线程安全；
epoll跨线程使用的注意事项；
高并发连接分发策略。

题目2：Reactor中EPOLLET+非阻塞IO的鲁棒性实现

题目描述

EPOLLET（边缘触发）是Reactor性能优化的关键，但易出现"数据读不完整""线程阻塞"问题，请完成：

解释为什么EPOLLET必须配合非阻塞IO使用？举例说明阻塞IO的坑；
用C++实现EPOLLET模式下的读事件处理逻辑（需完整处理EAGAIN/EINTR/EPIPE等错误码）；
对比LT（水平触发）和EPOLLET在Reactor中的选型依据。

考察点

epoll触发模式的底层原理；
C++非阻塞IO的实现；
系统调用错误码的鲁棒性处理；
性能与易用性的权衡。

题目3：Reactor模式下智能指针的内存安全管理

题目描述

Reactor中直接使用裸指针管理EventHandler（如Connection）易导致"野指针访问""内存泄漏"，请完成：

列举2个Reactor中EventHandler内存安全的典型坑点；
基于C++11的shared_ptr/weak_ptr设计安全的EventHandler管理方案（核心代码）；
说明"delete this"在Connection析构中的适用场景及风险。

考察点

C++智能指针的实战应用；
Reactor中FD与EventHandler的生命周期绑定；
析构安全（避免double free/野指针）。

题目4：Reactor处理TCP粘包/拆包的工业级方案

题目描述

TCP字节流特性导致Reactor服务端频繁出现粘包/拆包问题，请完成：

分析TCP粘包/拆包的核心原因；
基于"固定长度头+消息体"协议，用C++实现Reactor中Connection的粘包/拆包逻辑；
说明该方案在EPOLLET模式下的关键注意事项。

考察点

TCP协议特性；
Reactor中缓冲区的设计与管理；
工业级协议解析的鲁棒性；
EPOLLET模式下的边界处理。

题目5：Reactor vs 线程池+阻塞IO的性能对比与选型

题目描述

高性能网络编程中，Reactor（同步非阻塞）和"线程池+阻塞IO（BIO）"是两种常见方案，请完成：

从"并发数、资源开销、延迟、编程复杂度"四个维度对比两种方案；
给出不同业务场景下的选型依据（如连接数/业务耗时维度）；
用C++伪代码实现"线程池+阻塞IO"的核心逻辑，并说明其与Reactor的核心差异。

考察点

不同IO模型的性能权衡；
业务场景驱动的技术选型；
C++线程池的实现与Reactor的对比。

三、所有题目详解答案

题目1：主从Reactor架构设计与C++实现

1. 单Reactor单线程的核心瓶颈

事件循环阻塞：耗时业务逻辑（如10ms数据库查询）会卡住Reactor的epoll_wait循环，导致新连接/读写事件无法及时处理；
多核利用率低：单线程无法利用CPU多核，硬件资源浪费；
单点性能上限：单个epoll实例的事件处理能力受限于单线程的IO/计算瓶颈。

2. 主从Reactor架构设计

架构图：

复制代码

┌─────────────────┐
│ 主Reactor线程   │ → 仅处理监听FD的连接事件
│ （epoll+accept）│
└─────────┬───────┘
          │ （轮询/哈希分发连接）
┌─────────┼───────┐ ┌─────────┼───────┐ ┌─────────┼───────┐
│ 从Reactor线程1 │ │ 从Reactor线程2 │ │ 从Reactor线程N │
│ （epoll+IO事件）│ │ （epoll+IO事件）│ │ （epoll+IO事件）│
└─────────┬───────┘ └─────────┬───────┘ └─────────┬───────┘
          │                   │                   │
┌─────────┼───────────────────┼───────────────────┼───────┐
│ 业务线程池（可选）          │                   │       │
│ （处理耗时逻辑，不阻塞IO）  │                   │       │
└───────────────────────────────────────────────────────┘

组件职责：

主Reactor：仅管理监听FD，调用accept接受新连接，通过轮询/哈希策略将客户端FD分发到从Reactor；
从Reactor：每个从Reactor绑定独立线程和epoll实例，仅处理客户端FD的读写事件（轻量IO操作）；
业务线程池：耗时业务逻辑（如数据库查询）剥离到线程池，避免阻塞从Reactor的事件循环。

3. 核心C++伪代码

cpp 复制代码

#include <thread>
#include <vector>
#include <mutex>
#include <sys/epoll.h>
#include <unistd.h>
#include <fcntl.h>

// 设置FD为非阻塞
void set_nonblock(int fd) {
    int flags = fcntl(fd, F_GETFL, 0);
    fcntl(fd, F_SETFL, flags | O_NONBLOCK);
}

// 从Reactor类（每个实例独立线程+epoll）
class SubReactor {
public:
    SubReactor() {
        epoll_fd_ = epoll_create1(EPOLL_CLOEXEC);
        thread_ = std::thread(&SubReactor::run, this); // 启动从Reactor线程
    }

    ~SubReactor() {
        thread_.join();
        close(epoll_fd_);
    }

    // 注册客户端FD（跨线程调用需加锁）
    void add_client(int client_fd) {
        std::lock_guard<std::mutex> lock(mtx_);
        epoll_event ev{};
        ev.data.fd = client_fd;
        ev.events = EPOLLIN | EPOLLET; // 边缘触发+读事件
        epoll_ctl(epoll_fd_, EPOLL_CTL_ADD, client_fd, &ev);
    }

    // 从Reactor事件循环（仅处理IO事件）
    void run() {
        epoll_event events[1024];
        while (true) {
            int n = epoll_wait(epoll_fd_, events, 1024, -1);
            for (int i = 0; i < n; ++i) {
                handle_io(events[i].fd, events[i].events); // 仅处理轻量IO
            }
        }
    }

private:
    void handle_io(int fd, int events) {
        // 仅处理读/写事件，耗时逻辑抛到业务线程池
        if (events & EPOLLIN) { /* 读数据，抛到线程池 */ }
        if (events & EPOLLOUT) { /* 写数据 */ }
    }

    int epoll_fd_;
    std::thread thread_;
    std::mutex mtx_; // 保护epoll_ctl跨线程调用
};

// 主Reactor类（仅处理连接）
class MainReactor {
public:
    MainReactor(int listen_fd) : listen_fd_(listen_fd), next_sub_(0) {
        epoll_fd_ = epoll_create1(EPOLL_CLOEXEC);
        // 注册监听FD
        epoll_event ev{};
        ev.data.fd = listen_fd_;
        ev.events = EPOLLIN;
        epoll_ctl(epoll_fd_, EPOLL_CTL_ADD, listen_fd_, &ev);

        // 创建4个从Reactor（适配4核CPU）
        for (int i = 0; i < 4; ++i) {
            subs_.emplace_back(new SubReactor());
        }
    }

    // 主Reactor事件循环
    void run() {
        epoll_event events[16];
        while (true) {
            int n = epoll_wait(epoll_fd_, events, 16, -1);
            for (int i = 0; i < n; ++i) {
                if (events[i].fd == listen_fd_ && (events[i].events & EPOLLIN)) {
                    // 接受新连接（非阻塞）
                    int client_fd = accept4(listen_fd_, nullptr, nullptr, SOCK_NONBLOCK);
                    set_nonblock(client_fd);
                    // 轮询分发到从Reactor
                    subs_[next_sub_]->add_client(client_fd);
                    next_sub_ = (next_sub_ + 1) % subs_.size();
                }
            }
        }
    }

private:
    int listen_fd_;
    int epoll_fd_;
    int next_sub_;
    std::vector<std::unique_ptr<SubReactor>> subs_;
};

题目2：Reactor中EPOLLET+非阻塞IO的鲁棒性实现

1. EPOLLET必须配合非阻塞IO的原因

EPOLLET的核心特性是"仅在事件状态从无到有时触发一次"（如socket缓冲区从空到有数据），而非"只要有数据就触发"。

若用阻塞IO：当socket缓冲区剩余部分数据未读完时，EPOLLET不会再次触发读事件，此时调用read会阻塞线程，导致Reactor事件循环卡死；
示例：客户端分两次发"hello"+"world"，服务端第一次read读到"hello"后，缓冲区还有"world"，但EPOLLET不再触发读事件，阻塞IO的read会一直等待，无法处理其他连接。

2. EPOLLET+非阻塞IO的读事件处理代码

cpp 复制代码

#include <unistd.h>
#include <errno.h>
#include <string>
#include <iostream>

// EPOLLET模式下的读事件处理（完整错误码）
void handle_epollet_read(int fd) {
    char buf[4096];
    std::string recv_data;
    while (true) {
        ssize_t n = read(fd, buf, sizeof(buf));
        if (n > 0) {
            recv_data.append(buf, n); // 累加数据
        } else if (n == 0) {
            // 客户端关闭连接
            std::cout << "Client closed, fd=" << fd << std::endl;
            close(fd);
            return;
        } else {
            // 处理错误码
            if (errno == EAGAIN || errno == EWOULDBLOCK) {
                // 数据已读完，处理业务逻辑
                std::cout << "Read complete: " << recv_data << std::endl;
                break;
            } else if (errno == EINTR) {
                // 系统调用被信号中断，继续读
                continue;
            } else if (errno == EPIPE) {
                // 管道破裂（客户端异常关闭）
                std::cerr << "EPIPE, fd=" << fd << std::endl;
                close(fd);
                return;
            } else {
                // 其他错误（如EBADF）
                perror("read error");
                close(fd);
                return;
            }
        }
    }
}

3. LT与EPOLLET的选型依据

维度	水平触发（LT）	边缘触发（EPOLLET）
触发逻辑	只要有数据/可写，持续触发	仅状态变化时触发一次
编程复杂度	低（无需循环读/写）	高（需循环读/写直到EAGAIN）
性能	低（频繁触发，系统调用多）	高（减少触发次数，系统调用少）
选型场景	1. 小数据量、低频读写； 2. 新手开发（易调试）； 3. 跨平台（select/poll仅支持LT）	1. 大数据量、高频读写（如文件传输）； 2. 高性能服务（Nginx/Redis）； 3. 低延迟场景（金融交易）

题目3：Reactor模式下智能指针的内存安全管理

1. Reactor中EventHandler的典型坑点

坑点1：野指针访问：客户端断开连接后，未从Reactor注销FD就释放Connection，epoll回调时访问已析构的对象；
坑点2：内存泄漏/重复释放：Reactor注销FD后未释放Connection，或多线程下重复调用delete导致double free。

2. 智能指针安全管理方案

核心思路：用shared_ptr管理EventHandler生命周期，Reactor中存储weak_ptr（避免循环引用），回调时先lock()判断对象是否存活。

cpp 复制代码

#include <memory>
#include <unordered_map>
#include <mutex>

// 事件处理器基类（继承enable_shared_from_this）
class EventHandler : public std::enable_shared_from_this<EventHandler> {
public:
    virtual ~EventHandler() = default;
    virtual int get_fd() const = 0;
    virtual void handle_event(int events) = 0;
};

// Reactor类（存储weak_ptr，避免循环引用）
class Reactor {
public:
    // 注册事件：传入shared_ptr
    void add_event(std::shared_ptr<EventHandler> handler, int events) {
        std::lock_guard<std::mutex> lock(mtx_);
        int fd = handler->get_fd();
        epoll_event ev{};
        ev.data.ptr = handler.get(); // 存储原始指针
        ev.events = events | EPOLLET;
        epoll_ctl(epoll_fd_, EPOLL_CTL_ADD, fd, &ev);
        fd_to_handler_[fd] = handler; // 存储weak_ptr
    }

    // 事件分发（核心：检查对象是否存活）
    void dispatch(epoll_event& ev) {
        std::lock_guard<std::mutex> lock(mtx_);
        EventHandler* raw_ptr = static_cast<EventHandler*>(ev.data.ptr);
        if (!raw_ptr) return;

        auto it = fd_to_handler_.find(raw_ptr->get_fd());
        if (it == fd_to_handler_.end()) return;

        // 升级weak_ptr为shared_ptr，判断对象是否存活
        std::shared_ptr<EventHandler> handler = it->second.lock();
        if (handler) {
            handler->handle_event(ev.events); // 安全调用
        } else {
            // 对象已析构，注销FD
            epoll_ctl(epoll_fd_, EPOLL_CTL_DEL, raw_ptr->get_fd(), nullptr);
            fd_to_handler_.erase(it);
        }
    }

private:
    int epoll_fd_ = epoll_create1(EPOLL_CLOEXEC);
    std::mutex mtx_;
    std::unordered_map<int, std::weak_ptr<EventHandler>> fd_to_handler_;
};

// Connection类（EventHandler子类）
class Connection : public EventHandler {
public:
    Connection(int fd, Reactor* reactor) : fd_(fd), reactor_(reactor) {
        set_nonblock(fd_);
    }

    int get_fd() const override { return fd_; }

    void handle_event(int events) override {
        if (events & EPOLLIN) {
            handle_read();
        } else if (events & EPOLLERR) {
            // 安全注销：通过shared_from_this获取自身shared_ptr
            std::shared_ptr<Connection> self = shared_from_this();
            reactor_->del_event(self); // 注销事件
            // 无需手动delete，shared_ptr自动释放
        }
    }

private:
    void handle_read() {
        char buf[4096];
        ssize_t n = read(fd_, buf, sizeof(buf));
        if (n == 0) {
            // 客户端关闭，触发释放
            std::shared_ptr<Connection> self = shared_from_this();
            reactor_->del_event(self);
        }
    }

    int fd_;
    Reactor* reactor_;
};

3. "delete this"的适用场景与风险

适用场景：无智能指针时，Connection在"客户端断开/错误事件"中自行释放（如handle_read中检测到n==0时）；
核心风险 ：
1. 仅能在成员函数中调用，且对象必须是new创建（栈对象调用delete this会崩溃）；
2. 调用后不能访问任何成员变量/函数（对象已析构）；
3. 避免重复调用：需加标志位确保仅执行一次；
4. 推荐替代：优先使用shared_ptr，无需手动调用delete this。

题目4：Reactor处理TCP粘包/拆包的工业级方案

1. TCP粘包/拆包的核心原因

TCP是"面向字节流"的协议，无消息边界，粘包/拆包由以下原因导致：

发送方：Nagle算法合并小包，或连续发送多个消息时内核合并；
接收方：缓冲区未满时不触发读事件，导致多个消息被缓存；
网络层：IP分片、MTU限制导致消息被拆分。

2. "固定长度头+消息体"解包逻辑

协议格式：4字节长度头（网络字节序） + 消息体，Connection维护接收缓冲区，循环解析完整消息。

cpp 复制代码

#include <cstdint>
#include <arpa/inet.h> // ntohl/htonl

class Connection : public EventHandler {
public:
    Connection(int fd, Reactor* reactor) 
        : fd_(fd), reactor_(reactor), state_(READ_HEADER) {
        set_nonblock(fd_);
        header_buf_.resize(4); // 长度头固定4字节
    }

    void handle_event(int events) override {
        if (events & EPOLLIN) {
            read_data(); // 读取数据到缓冲区
            parse_data(); // 解析粘包/拆包
        }
    }

private:
    enum ParseState { READ_HEADER, READ_BODY }; // 解析状态

    // 读取数据到接收缓冲区（EPOLLET需循环读）
    void read_data() {
        char buf[4096];
        while (true) {
            ssize_t n = read(fd_, buf, sizeof(buf));
            if (n > 0) {
                recv_buf_.append(buf, n);
            } else if (errno == EAGAIN) {
                break; // 数据读完
            } else {
                close(fd_);
                return;
            }
        }
    }

    // 解析粘包/拆包
    void parse_data() {
        while (true) {
            if (state_ == READ_HEADER) {
                // 未读满长度头，退出
                if (recv_buf_.size() < 4) break;
                // 解析长度头（网络字节序转主机字节序）
                uint32_t body_len = 0;
                memcpy(&body_len, recv_buf_.data(), 4);
                body_len = ntohl(body_len);
                // 校验长度（防止恶意数据）
                if (body_len > 1024 * 1024) { // 限制最大1MB
                    close(fd_);
                    return;
                }
                body_buf_.resize(body_len);
                state_ = READ_BODY;
                recv_buf_.erase(0, 4); // 移除已解析的长度头
            }

            if (state_ == READ_BODY) {
                // 未读满消息体，退出
                if (recv_buf_.size() < body_buf_.size()) break;
                // 拷贝消息体
                memcpy(body_buf_.data(), recv_buf_.data(), body_buf_.size());
                // 处理完整消息
                handle_complete_msg(body_buf_.data(), body_buf_.size());
                // 清理缓冲区，重置状态
                recv_buf_.erase(0, body_buf_.size());
                state_ = READ_HEADER;
            }
        }
    }

    void handle_complete_msg(const char* data, size_t len) {
        std::cout << "完整消息：" << std::string(data, len) << std::endl;
        // 业务逻辑处理...
    }

    int fd_;
    Reactor* reactor_;
    ParseState state_;
    std::string recv_buf_;    // 接收缓冲区
    std::vector<char> header_buf_; // 长度头缓冲区
    std::vector<char> body_buf_;   // 消息体缓冲区
};

3. EPOLLET模式下的注意事项

必须循环read直到EAGAIN：确保socket缓冲区所有数据都被读入recv_buf_，避免消息残留；
长度头校验：必须限制最大消息长度，防止恶意客户端发送超大长度导致缓冲区溢出；
字节序转换：长度头需用ntohl/htonl处理网络字节序（大端）与主机字节序的差异；
缓冲区复用：避免频繁resize，可预分配固定大小缓冲区（如1MB），减少内存分配开销；
状态重置：解析完一条消息后必须重置state_为READ_HEADER，否则会持续解析错误。

题目5：Reactor vs 线程池+阻塞IO的性能对比与选型

1. 两种方案的核心对比

维度	Reactor（同步非阻塞+IO多路复用）	线程池+阻塞IO（BIO）
并发数	支持数万~数十万并发（低资源开销）	仅支持数百~数千并发（线程数受限）
资源开销	低（少量线程，无频繁上下文切换）	高（每个连接一个线程，上下文切换频繁）
延迟	低（仅处理就绪事件，无阻塞）	高（线程切换、阻塞等待数据）
编程复杂度	高（需处理非阻塞IO、事件分发）	低（线性逻辑，易调试）

2. 选型依据

业务场景	推荐方案	核心原因
高并发（>1万连接）	Reactor	线程数可控，避免资源耗尽
低并发+高耗时业务逻辑	线程池+阻塞IO	编程简单，无需处理非阻塞IO的复杂逻辑
低延迟场景（金融交易）	Reactor+EPOLLET	减少系统调用和上下文切换，降低延迟
新手开发/快速迭代	线程池+阻塞IO	调试成本低，开发效率高
跨平台需求	Reactor（select/poll）	select/poll跨平台，BIO跨平台但并发受限

3. 线程池+阻塞IO的核心逻辑及与Reactor的差异

cpp 复制代码

#include <thread>
#include <vector>
#include <queue>
#include <mutex>
#include <condition_variable>

// 简单线程池实现
class ThreadPool {
public:
    ThreadPool(int num) : stop_(false) {
        for (int i = 0; i < num; ++i) {
            threads_.emplace_back([this]() {
                while (true) {
                    std::function<void()> task;
                    {
                        std::unique_lock<std::mutex> lock(mtx_);
                        cv_.wait(lock, [this]() {
                            return stop_ || !tasks_.empty();
                        });
                        if (stop_ && tasks_.empty()) return;
                        task = std::move(tasks_.front());
                        tasks_.pop();
                    }
                    task(); // 执行任务（处理客户端连接）
                }
            });
        }
    }

    ~ThreadPool() {
        {
            std::lock_guard<std::mutex> lock(mtx_);
            stop_ = true;
        }
        cv_.notify_all();
        for (auto& t : threads_) t.join();
    }

    void add_task(std::function<void()> task) {
        std::lock_guard<std::mutex> lock(mtx_);
        tasks_.emplace(std::move(task));
        cv_.notify_one();
    }

private:
    std::vector<std::thread> threads_;
    std::queue<std::function<void()>> tasks_;
    std::mutex mtx_;
    std::condition_variable cv_;
    bool stop_;
};

// 线程池+阻塞IO的服务端核心逻辑
void server_bio(int listen_fd) {
    ThreadPool pool(10); // 固定10个线程
    while (true) {
        // 阻塞accept（BIO）
        int client_fd = accept(listen_fd, nullptr, nullptr);
        // 每个连接分配一个线程处理（阻塞IO）
        pool.add_task([client_fd]() {
            char buf[4096];
            while (true) {
                // 阻塞read（BIO）
                ssize_t n = read(client_fd, buf, sizeof(buf));
                if (n <= 0) break;
                // 阻塞write（BIO）
                write(client_fd, buf, n);
            }
            close(client_fd);
        });
    }
}

与Reactor的核心差异：

IO模型：BIO是"阻塞IO"，read/write/accept都会阻塞线程；Reactor是"非阻塞IO"，仅epoll_wait阻塞；
并发模型：BIO是"一个连接一个线程"，Reactor是"少量线程处理所有连接"；
事件处理：BIO是"主动读取数据"，Reactor是"事件驱动，数据就绪后才处理"；
资源占用：BIO线程数随连接数线性增长，Reactor线程数固定（主从Reactor仅N+1个线程）。