muduo网络库（八）：EventLoop 事件循环

muduo网络库八EventLoop 事件循环muduo网络库八EventLoop 事件循环概述EventLoop 的内部结构loop 主循环跨线程唤醒机制为什么需要 wakeup跨线程投递流程doPendingFunctors 的巧妙设计One Loop Per Thread 多线程模型mainLoop 与 subLoops 的分工多线程协作时间线wakeup 如何融入流程单个 EventLoop 的生命周期muduo网络库八EventLoop 事件循环概述EventLoop相当于 muduo 的主反应堆其中包含了Channel类和Poller类。muduo 采用经典的One Loop Per Thread模型——每个线程拥有一个 EventLoop负责该线程内所有文件描述符的事件监听和回调分发。EventLoop 的核心职责可以概括为两点IO 事件分发通过 Poller 监听 fd事件就绪后调用 Channel 的回调跨线程任务执行通过 wakeupFd 唤醒机制让其他线程安全地投递任务到本线程执行EventLoop 的内部结构EventLoop ├── poller_ (EpollPoller) │ ├── epollFd_ ← epoll 实例 │ └── channels_ ← 所有注册的 fd │ ├── listenfd → Channel (主线程) │ ├── connfd1 → Channel (工作线程) │ ├── connfd2 → Channel (工作线程) │ └── ... ├── wakeupFd_ ← 跨线程唤醒用 └── wakeupChannel_ ← 封装 wakeupFd_除了 Poller 管理的 IO 通道外EventLoop 还有一个特殊的wakeupFd_——这是eventfd创建的文件描述符专门用于跨线程唤醒。当其他线程需要让当前 EventLoop 立即处理某个任务时就往这个 fd 写入数据让epoll_wait立刻返回。loop 主循环loop()是 EventLoop 的核心函数也是整个事件驱动引擎的心脏。它的执行流程如下┌──────────────────────────────────────────────────────────────────┐ │ EventLoop::loop() 主循环 │ ├──────────────────────────────────────────────────────────────────┤ │ ┌────────────────────────────────────────────────────────────┐ │ │ │ 1. EpollPoller::poll() → epoll_wait() 阻塞等待事件 │ │ │ └───────────────────────────┬────────────────────────────────┘ │ │ ↓ 有事件发生或被wakeup唤醒 │ │ ┌────────────────────────────────────────────────────────────┐ │ │ │ 2. fillActiveChannels() 收集活跃的 Channel │ │ │ └───────────────────────────┬────────────────────────────────┘ │ │ ↓ │ │ ┌────────────────────────────────────────────────────────────┐ │ │ │ 3. 遍历 activeChannels → Channel::handleEvent() │ │ │ │ ↓ │ │ │ │ 调用各回调readCallback_/writeCallback_/closeCallback_...│ │ │ └────────────────────────────────────────────────────────────┘ │ │ ↓ │ │ ┌────────────────────────────────────────────────────────────┐ │ │ │ 4. doPendingFunctors() 执行其他线程投递的任务 │ │ │ └────────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘其中channel-handleEvent()负责处理 epoll 返回的 IO 事件而doPendingFunctors()负责处理其他线程投递的任务。关键细节EventLoop 在构造函数中已经将 wakeupFd 的读回调绑定到handleRead函数所以当handleEvent()处理 wakeup 事件时实际上只是消费唤醒信号读取 8 字节数据真正的任务在pendingFunctors_队列中等待执行。跨线程唤醒机制为什么需要 wakeup假设线程 B 的 EventLoop 正在epoll_wait()中阻塞等待事件此时线程 A 想让它执行一个任务比如注册新的 Channel。如果不做特殊处理线程 B 根本不知道有任务到来只能等下一个 IO 事件到来才会醒来——这可能要等很久。wakeupFd_就是为了解决这个问题线程 A 往wakeupFd_写入数据epoll 立刻检测到可读事件线程 B 从epoll_wait()返回然后执行doPendingFunctors()处理任务。跨线程投递流程线程A 线程B (EventLoop线程) ┌─────────────────────────┐ ┌─────────────────┐ │ 线程池中获取subLoop │ │ │ │ runInLoop(func) │ │ poll() 阻塞等待 │ │ └─ isInLoopThread() → false │ │ │ └─ queueInLoop(func) │ │ │ ├─ func → queue │ │ │ └─ wakeup() │ │ │ │ │ │ │ ▼ │ │ │ write(wakeupFd) ──────────▶ poll()返回│ │ │ │ │ │ │ │ handleEvent(wakeupChannel)│ │ │ │ └─ read(wakeupFd) 消费信号│ │ │ │ │ │ │ │ doPendingFunctors() │ │ │ │ └─ 执行 task │ │ │ │ │ └─────────────────────────┘ └─────────────────┘当线程 A 向线程 B 投递任务时先将任务放入pendingFunctors_队列加锁保护再调用wakeup()往wakeupFd_写入数据线程 B 的epoll_wait()检测到 wakeupFd 可读立即返回执行doPendingFunctors()依次处理队列中的任务wakeup 的作用只是让 epoll_wait 立即返回任务早就投入队列了。就算不立即唤醒下次有 IO 事件时也会调用doPendingFunctors()处理这些任务。但为了实时性通常需要立即唤醒。这种设计还有一个优势当批量投递多个任务时只需一次唤醒doPendingFunctors()会一次性处理所有积攒的任务。doPendingFunctors 的巧妙设计doPendingFunctors()不是直接遍历pendingFunctors_执行而是先将其交换到一个局部变量中voiddoPendingFunctors(){std::vectorFunctorfunctors;{MutexLockGuardlock(mutex_);functors.swap(pendingFunctors_);// 交换而非拷贝}for(constFunctorfn:functors){fn();// 在锁外执行}}这个swap设计非常精妙缩小临界区只在 swap 时加锁执行任务时不需要持锁减少锁竞争避免死锁任务内部可能再次调用runInLoop()如果执行时仍持锁就会死锁提高吞吐新投递的任务在执行期间可以继续加入队列下一轮循环再处理One Loop Per Thread 多线程模型mainLoop 与 subLoops 的分工muduo 的多线程模型遵循One Loop Per Thread原则mainLoop主线程的 EventLoop负责accept 新连接subLoopsN 个子线程的 EventLoop负责处理已连接的 IO 读写它们之间不靠消息队列、不靠管道、不靠复杂通信只靠wakeup() 锁 pendingFunctors_完成全部交互。多线程协作时间线时间线 → 主线程 mainLoop: poll() → 检测到 listenfd 可读 → accept() → 获取 connfd ↓ 将 connfd 封装为 Channel通过 queueInLoop() 发送到工作线程 ↓ 继续 poll() 等待下一个事件 工作线程 subLoop1: poll() 阻塞中 ←── 被 wakeupFd 唤醒 ↓ 执行 pendingFunctors 中的任务注册新 Channel ↓ poll() 继续监听 connfd 事件 ↓ 检测到 connfd 可读 → 调用 Channel 的 readCallback_wakeup 如何融入流程mainLoop 拿到新连接主线程accept到新的客户端连接mainLoop 把任务发给 subLoopsubLoop-runInLoop(把新连接交给你处理);runInLoop 内部做两件事加锁 → 将任务放入pendingFunctors_→wakeup()唤醒 subLoopsubLoop 被唤醒后从doPendingFunctors()中取出函数swap 后依次执行wakeup 的本质往 subLoop 自己的 eventfd 写一个 8 字节数据让 subLoop 从epoll_wait()阻塞中立刻醒来。单个 EventLoop 的生命周期从 Channel 注册到事件处理的完整流程用户注册事件 ↓ Channel::enableXxx() → Channel::update() ↓ EventLoop::updateChannel() ← 新 channel 加入 channels_ Map ↓ EpollPoller::update() ↓ 根据 channel 的 index 判断是添加还是删除 epoll_ctl(ADD/MOD/DEL) ← 内核注册 注册完成后EventLoop 的 loop() 循环就会持续监听这些 fd一旦事件就绪就触发回调。 ## 设计精髓总结 | 设计点 | 做法 | 收益 | |--------|------|------| | One Loop Per Thread | 每线程一个 EventLoop | 线程内无需加锁避免竞争 | | wakeupFd 唤醒 | eventfd epoll 监听 | 跨线程通信低延迟立即可达 | | pendingFunctors | 任务队列 swap | 临界区最小化避免死锁 | | 事件驱动 | poll → handleEvent → doPendingFunctors | IO 与任务统一在事件循环中处理 | | mainLoop/subLoops | 主线程 accept子线程处理 IO | 新连接分发均衡扩展性强 | EventLoop 是 muduo 网络库的灵魂它将 Channel事件通道、PollerIO 复用、wakeupFd跨线程唤醒和 pendingFunctors任务队列有机整合构建了一个高效、可扩展、线程安全的事件驱动引擎。