企业官网建设流程全解析

Muduo 这个名字在 C++ 网络编程圈子里几乎没人不知道。它是一个基于 Reactor 模式的 Linux 多线程网络库，核心思路一句话就能讲清楚：每个线程跑一个事件循环，循环里统一管理所有感兴趣的 fd，事件一旦就绪就分发给对应的处理对象，业务方只需要填写回调函数就行。很多人第一眼看源码会觉得类特别多，EventLoop、Channel、Poller、Acceptor、TcpConnection、Buffer、TimerQueue……名字都认识，但串不起来。这篇内容就是帮你把这些模块全部串成一张能印在脑子里的架构图，顺便把最关键的实现细节、线程边界和踩坑点一起梳理出来。

不管你是刚接触网络编程的新手，还是已经在写服务端、想深入研究一个生产级网络库的进阶开发者，这套梳理都能用上。如果你是新手，它能给你一张“地图”，避免掉进源码里出不来；如果你已经在用 Muduo 做东西，那后面问题排查和架构图画法那几节，大概率能帮你省不少时间。

1. 为什么值得把 Muduo 架构完整梳理一遍

1.1 先用一句话说清 Muduo 是什么

Muduo 是一个把“事件循环 + 非阻塞 IO + epoll”组合封装成一套清晰对象模型的 C++ 网络库。它最基本的运行方式是这样：一个线程对应一个 EventLoop，这个 EventLoop 内部有一个 Poller 负责 epoll_wait，等待所有已注册 fd 的事件；一旦有事件发生，就通过 Channel 找到对应的回调，把事件处理掉。定时器也统一挂在事件循环里，通过 timerfd 变成“fd 可读事件”来处理。

如果打个比方，可以把 Muduo 想象成一家高效的前台客服中心。客服（EventLoop）盯着几条专线（fd），哪条线来电（事件就绪）就接哪条线（分发事件）。每个客服只处理自己负责的来电，互不干扰。业务代码只需要告诉客服“接起电话之后怎么回答”，剩下的监听、分派、转接都由框架完成。

1.2 不同基础的读者能从中得到什么

这里按三种情况说清楚。

刚接触网络编程的读者，最需要的是把“Reactor”“事件循环”“IO 复用”这些抽象概念落到具体类上。我会告诉你每个类到底负责什么、在什么时机被调用，而不是停留在概念层面。

已经写过一些服务端程序的读者，可以重点看线程模型、Buffer 实现和连接状态机。这三块是 Muduo 里最有学习价值的部分，很多其他网络库都借鉴了同样的设计。

打算把 Muduo 用在项目里、甚至做二次开发的读者，架构图最有用的一点就是能帮你快速定位“我要改哪里、加哪里”。比如想自定义 IO 复用方式，就动 Poller；想改连接生命周期管理，就盯 TcpServer 和 TcpConnection。不用把整个库翻一遍。

1.3 架构总结图的真正价值

很多人以为架构图是用来“展示给别人看”的，其实它最大的价值是给你自己提供一个定位坐标系。数据从网卡到业务代码经过了哪些对象，事件从发生到执行经过了哪些回调，这些路径在图上画清楚之后，出问题排查会快非常多。

尤其是多线程环境，跨线程边界是坑最多的地方。图上如果能把“哪个对象属于哪个线程”标出来，很多潜在的设计错误一眼就能看出来。所以这份架构总结图的核心目的不是画得好看，而是帮你在脑子里建立一个可折叠的索引结构，读代码时按图索骥。

2. 整体分层与模块地图

2.1 从使用视角看三层结构

Muduo 源码虽然平铺直叙，但逻辑上可以分成三层。理解这三层，后面所有细节都不会乱。

这里要注意，业务接入层不是 Muduo 自带的，但它决定了 Muduo 能发挥多少价值。框架只保证“一个完整 TCP 消息能被可靠地收上来”，至于消息怎么拆包、怎么组合成业务对象、要不要在独立线程池里处理，都是这一层的事。

2.2 模块之间的依赖关系

先看基础设施层内部：EventLoop 拥有 Poller、TimerQueue、wakeupFd 和 pendingFunctors 队列。Poller 管理 fd 到 Channel 的映射，事件就绪时把 activeChannels 交给 EventLoop。Channel 是被动对象，它不知道自己什么时候会被 poll 到，只负责在事件发生时执行注册好的回调。

再看网络服务层：Acceptor 负责监听 fd，它自己也是一个 Channel 的使用者。当监听 fd 可读时，Acceptor 执行 accept，拿到新连接 fd 后通过回调交给 TcpServer。TcpServer 再把它包装成 TcpConnection，分配到某个 sub loop 上。

TcpConnection 是单个连接的对象，它内部拥有一个 Channel、一个 inputBuffer、一个 outputBuffer，并且强绑定一个 EventLoop。Buffer 负责暂存未读完或未写完的数据；Channel 负责把 fd 事件转发给 TcpConnection 的回调。TcpServer 则持有 Acceptor、线程池和连接表，是唯一能把这些东西全部串起来的组装类。

2.3 一张可直接记到脑子的文字版全景图

下面这张 ASCII 图不是 Mermaid 那种自动生成的图，而是我建议你在笔记本上也画一份的简化版本。重点看箭头方向：谁触发谁、谁归谁管理。

┌─────────────────────────────┐ │ TcpServer │ │ Acceptor + 线程池 + 连接表 │ └───┬─────────────┬───────────┘ │ accept │ 按轮询分配 EventLoop ↓ ↓ ┌────────────┐ ┌───────────────────────┐ │ Main Loop │ │ Sub Loop 1/2/3/... │ │ Acceptor │ │ (每个线程一个 EventLoop)│ └────────────┘ └──────────┬────────────┘ ↓ ┌─────────────────────────────┐ │ Poller │ │ epoll_wait + fd->Channel │ └─────────────────────────────┘ ↓ ┌─────────────────────────────┐ │ TcpConnection 实例集合 │ │ Channel/inputBuffer/ │ │ outputBuffer │ └─────────────────────────────┘

围绕这张图，有几个必记的关联点：

• Acceptor 属于 main loop，监听 fd 只在 main loop 里被 poll。
• 新连接被分配到某个 sub loop 后，这个连接上的所有事件都只由该 sub loop 处理。
• 每个 EventLoop 都有自己的 Poller、TimerQueue 和 wakeupFd，三者都是独立实例。
• 定时器和网络事件睡在同一个事件循环里。不是单独开一个线程去跑定时任务。

画图时最容易犯的错，是把 EventLoopThread 和 EventLoop 画成一个东西。EventLoopThread 只是线程包装，真正干活的是里面那个 EventLoop。

3. 核心组件逐个拆解

3.1 EventLoop：事件循环的心脏

EventLoop 的对外核心就是一个 loop() 方法。它做的事情在代码层面可以概括成三步循环：第一步，调用 poller_->poll() 获取当前所有就绪的 Channel；第二步，逐个调用这些 Channel 的 handleEvent 处理事件；第三步，执行 pendingFunctors 里积压的跨线程任务。

每轮循环之间是紧密串联的，前一轮任务没执行完，下一轮 poll 就不会开始。这也意味着，任何在回调里做的耗时操作都会堵塞整个事件循环。

EventLoop 内部有几个关键成员，缺一不可：

• poller：IO 复用的具体实现，通常是 epoll 封装。
• activeChannels：每次 poll 返回的就绪 Channel 列表。
• timerQueue：定时器队列，负责管理所有定时任务。
• wakeupFd：一个 eventfd，专门用来唤醒 loop 线程。
• pendingFunctors：跨线程投递过来的任务队列。
• threadId：创建这个 EventLoop 的线程 ID，用于断言线程归属。

wakeupFd 特别值得拿出来说一下。它本身也注册成了一个 Channel，只要其它线程向它写入一个字节，当前 loop 的 epoll_wait 就会立刻返回。这样就能把别的线程想执行的代码，安全地换到 loop 线程里来跑。

3.2 Channel：事件分发的最小单元

Channel 是理解 Muduo 的一把钥匙。一个 Channel 对应一个 fd，它内部保存了 fd 的值、关注的事件掩码，以及一系列回调函数。

事件发生时，Poller 会根据 epoll 返回的事件类型设置 Channel 的 revents 字段，然后调用 handleEvent。handleEvent 内部就是简单的分发逻辑：如果 revents 包含可读事件，就调用读回调；如果包含可写事件，就调用写回调。至于是不是真的要读、要写，那属于上层对象（通常就是 TcpConnection）的事。

有一个关键点：Channel 不拥有 fd。fd 的真正所有者是 TcpConnection 或者 Acceptor。它们的析构函数会负责关闭 fd，Channel 只在它们生命周期内使用这个 fd。

还有一点，Channel 的 enableReading / enableWriting 这类操作，必须在它所归属的 EventLoop 线程里调用。如果需要从别的线程改事件，得借助 EventLoop::runInLoop 把操作转移过去。

3.3 Poller：epoll 外层封装

Poller 的职责非常单一：告诉 EventLoop“现在哪些 fd 上发生了哪些事情”。它内部维护一个 fd 到 Channel 的映射表，这样 epoll_event 返回时，可以通过 data.fd 快速找到 Channel。

每次 poll 调用大概是这个流程：

1. 调用 epoll_wait，等待事件或者超时。
2. epoll_wait 返回后，遍历 events 数组。
3. 对每个事件，根据 fd 从映射表拿到 Channel。
4. 把 revents 填进 Channel。
5. 把 Channel 加入 activeChannels 列表。

updateChannel 这个接口负责处理 EPOLL_CTL_ADD 和 EPOLL_CTL_MOD 两种操作。如果当前 fd 第一次注册，就 ADD；如果之前已经注册过，只是修改关注事件，就 MOD。这里涉及一个细节：同一个 fd 可能在更新事件前后有短暂的时间窗口，只要别用裸 epoll 直接操作，而是走 Muduo 封装，就不会出问题。

3.4 TimerQueue：定时器为什么挂在事件循环里

TimerQueue 让 EventLoop 支持定时任务，它被设计成不使用独立线程，而是基于 timerfd 注册到 poller 上。定时器到期时，timerfd 变成可读状态，这就等于一次普通的事件通知，和网络事件没有任何区别。

实现上，TimerQueue 内部用一个有序结构保存所有定时器条目，每个条目包含到期时间、回调、定时器 ID。每次 poll 结束，EventLoop 在处理网络事件之前，会先看一下当前时间是否已经超过了最早的定时器到期时间。如果超过了，就把到期的定时器取出来执行，重复定时器再重新插回队列。

由于所有定时器都在事件循环线程里执行，定时回调一定不能做耗时操作。否则一个心跳回调里阻塞了 500 毫秒，整个 loop 上的所有连接都会被拖慢。这一点在业务代码里特别容易踩坑。

3.5 EventLoopThread 与线程池

EventLoopThread 的逻辑很简单：一个线程，一个 EventLoop。线程启动后，EventLoop 在该线程内创建并运行 loop()；事件循环退出时，线程也随之结束。EventLoopThreadPool 则负责管理多个这样的 worker，TcpServer 启动时按需创建。

新连接到来时，TcpServer 会调用线程池的 getNextLoop() 拿到一个 EventLoop，默认是简单的轮询分配。每个连接一旦分配到一个 loop，整个生命周期都固定在这个 loop 上。

在设计层面要注意，线程池里的 loop 线程数不是越多越好。Muduo 的模型里，每个 loop 是一个串行执行单元，如果业务回调太重，loop 反而会变成瓶颈。通常建议先按 CPU 核数设，再根据实际压测结果调整。业务逻辑如果偏重，更合理的做法是把计算任务投递到独立的业务线程池，让 loop 线程专心处理 IO。

4. 网络连接层与业务接入

4.1 Acceptor：新连接从哪里进来

Acceptor 负责监听端口，它在构造时会创建监听 socket，设置为非阻塞，并把监听 fd 注册到 main loop 的 Channel 上。当监听 fd 可读时，说明有新的 TCP 连接完成了三次握手，Acceptor 的 handleRead 会调用 accept 获取已连接 fd。

Muduo 在这里做了一个非常重要的解耦：Acceptor 并不负责创建 TcpConnection，它只是把拿到的新连接 fd 通过 newConnectionCallback 回调抛给 TcpServer。TcpServer 决定如何包装它、分配到哪个 loop、注册到连接表。这样监听逻辑和业务组装逻辑就彻底分开了。

有一点需要注意：accept 返回的已连接 fd 默认也是非阻塞的。在服务端编程里，这基本是标配，阻塞 fd 会让 IO 流程变得难以控制。

4.2 TcpConnection 的状态机

TcpConnection 是单连接对象，它的状态机非常典型，画架构图时一定不能漏。

状态可以简化为四条：Disconnected、Connecting、Connected、Disconnecting。

刚创建对象时处于 Connecting，此时还没有完成连接建立确认。当连接真正可用时进入 Connected，会触发 connectionCallback。如果业务方主动调用 shutdown，会进入 Disconnecting，此时可能还有数据在 outputBuffer 里没发完，需要等发送完成或者对端关闭。最终对端关闭或者本地关闭，状态进入 Disconnected，触发 closeCallback。

另一个关键点是 TcpConnection 的生命周期。它内部被 shared_ptr 管理，因为事件回调可能来自多个路径，在回调执行过程中对象不能提前析构。如果哪个模块直接持有裸指针并且跨线程使用，大概率会在连接关闭时踩到悬垂指针。

4.3 Buffer：三段式缓冲怎么工作

每个 TcpConnection 都有两个 Buffer：inputBuffer 和 outputBuffer。Buffer 的实现是 Muduo 里非常经典的一段代码，核心是“三段式”布局：头部的 prependable 预留区、中部的 readable 可读区、尾部的 writable 可写区。

维护两个索引 readIndex 和 writeIndex，readable 区就是 readIndex 到 writeIndex 之间的部分。读取数据时，业务从 readable 区取；写入数据时，从 writable 区尾部追加。

这个设计有一个很实用的好处：需要给消息加长度头或者其它协议前缀时，可以在 prependable 区域直接写，不用把整个消息内容搬来搬去。另外，当 writable 区扩容时，Buffer 会先把 readable 区旁边的空闲空间合并利用起来，尽量减少一次性扩容的次数。

写数据时，数据并不会直接调用 write 到 fd，而是先追加进 outputBuffer，再尝试发送。如果内核发送缓冲区可以一次性写入很多，那写事件就不会被注册。只有当一次写不完时，才打开 EPOLLOUT 写事件。

4.4 TcpServer：把所有模块串起来

TcpServer 是业务开发接触最多的类。它内部持有 Acceptor、EventLoopThreadPool，以及一个 map<string, shared_ptr > 连接表。

启动时，TcpServer 先让 Acceptor listen，然后启动线程池。每个连接建立后，TcpServer 负责在合适的 loop 里创建 TcpConnection，把连接加入连接表，同时把用户设置的回调（连接回调、消息回调、写完成回调）注册到该连接上。

关闭链路也很讲究。当连接断开被确认后，TcpServer 先从连接表里移除这个连接，随后 TcpConnection 的析构才会真正关闭 fd 和释放资源。顺序不能反过来，否则可能出现连接还在表里，但底层 fd 已经被释放的竞争。

5. 关键流程时序拆解

5.1 一个连接从建立到关闭的完整时间线

把时间线完整走一遍，比单看类定义要有用得多。

服务端启动后，main loop 里只有 Acceptor 的监听 fd 在 poll。线程池启动后，各 sub loop 也都在 epoll_wait 等待。

客户端发起 connect 时，内核完成三次握手，监听 fd 变为可读。main loop 的 poll 返回，Acceptor 的 Channel 触发 handleRead，accept 拿到新连接 fd。接下来 TcpServer 从线程池中选一个 sub loop，在这个 sub loop 内创建 TcpConnection，注册 Channel，并进入 Connected 状态。

数据收发阶段，客户端发来的数据会让该连接在 sub loop 中变成可读。Poller 返回后，Channel 触发读回调，数据进入 inputBuffer，然后进入业务 messageCallback。业务处理完，如果有响应要发，就调用 send，写入 outputBuffer 并通过写事件或直接 write 发送。

关闭时，对端关闭连接会让 read 事件返回 0，TcpConnection 启动关闭流程，移除 Channel，状态进入 Disconnected。随后 TcpServer 从连接表删除，最终由 shared_ptr 引用计数为零时析构对象。

整个流程里最重要的红线就是：这期间的操作全部必须发生在该连接所属的 loop 线程里。业务线程如果直接关连接，要小心线程安全问题。

5.2 数据读取与消息分发流程

数据读取的路径可以压缩成这么一段：

网络数据到达网卡，触发 fd 可读。sub loop 的 epoll_wait 返回，activeChannels 里出现该连接的 Channel。Channel::handleEvent 根据 revents 调用 handleRead。TcpConnection::handleRead 从 fd 读数据到 inputBuffer，然后调用 messageCallback。

这里有个细节很容易被忽略：Muduo 并不负责拆包。它只保证把字节流可靠地放进 inputBuffer，具体一个“消息”从哪里结束、下一个“消息”从哪里开始，需要业务代码自己判断。

所以实际项目中通常会在 messageCallback 里做协议解析，例如先读 2 字节长度头，再根据长度读 body。这也是为什么网上能看到很多基于 Muduo 的 LengthHeaderCodec 或类似编解码器，它们都是在业务接入层封装出来的。

5.3 数据发送与写事件处理

发送比接收复杂一点，核心难点在于避免忙轮询。

业务调用 TcpConnection::send 时，数据会先追加到 outputBuffer。然后框架尝试直接 write 到 fd。如果能一次写完，那这次发送就结束了，不需要注册写事件。如果内核发送缓冲区不够，一次 write 只写了一部分，剩余数据还留在 outputBuffer，这时就需要注册 EPOLLOUT 写事件。

当 fd 可写时，epoll_wait 返回写事件，TcpConnection::handleWrite 继续从 outputBuffer 里取数据发送。发完之后，必须立刻关闭写事件，否则 fd 持续可写，epoll 会不断返回写事件，CPU 直接被打满。

我见过不少自研网络框架的忙轮询问题，基本都栽在这一条上：写事件注册了，但发完没有注销。

5.4 跨线程任务的投递与执行

跨线程使用连接，是网络编程里绕不开的话题。比如一个业务线程想给某个连接发送一条消息，但这个连接属于另一个 loop。如果直接操作 Channel，会产生数据竞争。Muduo 给出的标准解法是投递任务。

调用 EventLoop::runInLoop 时，如果当前线程正好是目标 loop 的线程，那就直接执行。如果不是，就调用 queueInLoop。queueInLoop 会把任务放进 pendingFunctors，然后向 wakeupFd 写入一个字节。

目标 loop 被 wakeupFd 唤醒后，先把这个 fd 读干净，再依次执行 pendingFunctors 里的任务。这个“换线程执行”的过程，保证了后续对连接对象的操作全部发生在正确的线程里。

这里有一个执行顺序问题：pendingFunctors 的执行是成批的，不是执行一个就重新 poll 一次。所以如果队列里任务太多，或者某个任务执行过久，依然会影响事件循环的响应能力。投递任务时也要尽量保证任务本身轻量。

6. 多线程模型与线程安全设计

6.1 one loop per thread 到底意味着什么

one loop per thread 的精髓在于“一个 loop 永远只属于一个线程”。创建它的线程是它唯一合法的所有者，所有和这个 loop 相关的事件处理、定时器回调、任务队列操作，都必定发生在同一个线程里。

这个模型的最大优势是串行化。同一个连接上的所有事件，在处理时天然串行，不需要加锁。多个连接之间如果不存在共享状态，那整个程序的核心路径可以是完全无锁的，这也是 Muduo 在并发场景下表现好的原因。

当然，串行化不是免费的。它意味着单个 loop 线程成为该连接的绝对瓶颈，任何一个回调的耗时都会拖慢同 loop 上的其它连接。所以实际编码习惯应该是一切回调从简，重活一律丢到业务线程池。

6.2 哪些对象不能跨线程操作

从线程归属角度，可以把对象分成几类，画图时最好用虚线标出线程边界。

EventLoop、Poller、TimerQueue、Channel，这些基础设施对象只能在所属 loop 线程内操作。TcpConnection 的数据收发、状态变更、关闭操作，原则上也必须通过 runInLoop 回到所属 loop 执行。Acceptor 和 main loop 绑定，所以在 main loop 里操作。

业务线程能碰的东西不多：设置回调、向队列投递任务、读一些不会变的配置信息。如果需要让连接发消息，那就调用 send 或者投递一个任务，千万别直接拿 Channel 去 enableWriting。

6.3 用到的同步原语

Muduo 并不是完全无锁，它把锁用到了点子上。

MutexLock 主要用于保护两类数据：连接表和 pendingFunctors。连接表在 TcpServer 中，允许多个线程同时访问；pendingFunctors 虽然执行时在 loop 线程内，但入队时可能来自任意线程，所以入队操作需要加锁。

Condition 主要用于 EventLoopThread 的同步启动。因为主线程需要确保子线程的 EventLoop 真正创建完成，才能把 loop 指针返回给业务层，所以需要条件变量等待初始化完成。

此外，计数器、自增 ID 这类简单场景使用原子操作。整体设计倾向是：能用线程归属解决的问题就不加锁，必须跨线程传递信息时才用极少的锁。

6.4 什么时候需要额外加锁

这里要泼一盆冷水：one loop per thread 不保证业务数据线程安全。Muduo 只保证网络事件层的安全，如果业务代码里有一个全局计数器、在线用户表，或者任何多个连接共享的状态，必须自己加锁。

一个常见反例是：业务线程池里多个线程处理消息时，同时写同一个用户状态对象，以为框架线程安全就没事，结果数据错乱。事实是，框架的线程模型只解决了“网络事件不抢数据”，不解决“业务逻辑不抢数据”。这两层要分清楚。

7. 常见问题与排查技巧实录

7.1 事件循环卡死，业务全挂

最典型的故障表现是：某一时刻开始，所有连接都没有新事件进来，服务整体不可用。

原因基本都出在 loop 回调里。messageCallback 里做了耗时操作是头号嫌疑，其次是回调里等待一个永远等不到的信号，或者直接死循环。

排查时先看该线程的 CPU 使用率：如果某个 loop 线程 CPU 接近 100%，大概率卡在某个回调里。用调试器抓线程栈，就能看到当前到底在哪个函数里出不来。

解决办法也很直接：把耗时操作从回调里挪出去。回调里只做协议解析、数据投递这类轻量工作，真正重的业务计算放到业务线程池。这个原则在写 Muduo 业务代码时应该当成铁律。

7.2 连接频繁断开或表现异常

连接掉线问题比卡死更隐蔽。常见原因有三类。

第一类，在错误的线程操作了 TcpConnection。业务线程直接调用 shutdown 或 close，而该连接属于另一个 loop，导致状态机错乱。正确做法是 runInLoop 到连接所属线程里操作。

第二类，生命周期提前释放。TcpConnection 在连接关闭回调里被业务代码移除引用，但事件可能还在执行，形成悬垂指针。这个问题的根源在于没有遵循 shared_ptr 的使用规范。

第三类，对端已经关闭，但本地还在继续 write。实际表现可能是收到 SIGPIPE 信号，或者 write 返回错误。

排查时建议把连接建立、关闭、字节收发都打上日志，把时间线拉出来看。断开前最后一条日志往往就能说明问题。

7.3 忙轮询和 CPU 飙高

忙轮询的表现是 CPU 虚高但不卡死，事件循环在疯狂空转。典型原因是写事件没有在数据发完后关闭。fd 一直可写，EPOLLOUT 就一直返回，Poller 就一直把同一个 Channel 加入 activeChannels，造成无意义的大量循环。

另一个容易忽视的源头是 wakeupFd 里的数据没有读干净。向 wakeupFd 写入的数据如果不消费掉，它会一直保持可读，epoll 也会一直返回。所以 EventLoop 里每次唤醒后都要先读走 wakeupFd 的数据，再执行任务。

排查时用 perf 或 top 看线程卡在哪个系统调用上，如果是 epoll_wait 频繁返回但没有实际业务处理，基本就是这两种情况之一。

7.4 定时器任务延迟

定时器不准的场景通常是这样：心跳超时误判，或者计划任务比预期晚执行。

原因和事件循环卡死类似，定时器回调本身太重。Muduo 的定时器回调是在 loop 线程里执行的，一个定时回调如果耗时几十毫秒，其它到期的定时器和网络事件都要排队。

另外，如果有序定时器队列一次性积压了大量任务，一轮里会处理很久。排查时可以关注定时回调里是否调用了网络发送、磁盘 IO 或者锁等待。最好的实践是定时回调只做“决定”，不做“执行”。需要落地的事通过任务队列交到业务线程池执行。

7.5 架构图画错的典型位置

这节是给想自己画“Muduo 全套架构总结图”的读者看的，我见过太多图在几个固定地方栽跟头。

第一个是把 EventLoopThread 和 EventLoop 画成同一个类。EventLoopThread 只是线程和 loop 的包装器，真正的事件循环逻辑全在 EventLoop 里，画图时最好分开画。

第二个是把 TcpConnection 画在 TcpServer 之外、看起来像独立线程。实际上 TcpConnection 确实运行在 sub loop 线程中，但它受 TcpServer 管理，生命周期也被 TcpServer 控制。图里应该体现“TcpServer 拥有连接表，连接绑定了某 sub loop”这种双重关系。

第三个是忘记画 wakeupFd 和 pendingFunctors。没有它们，跨线程投递任务这件事在架构图上就是断的，而这是 Muduo 线程安全设计里非常重要的一环。

第四个是只画 inputBuffer，漏掉 outputBuffer。写事件处理和 outputBuffer 是强绑定的，少画了它，发送流程就不完整。

7.6 高频排查速查表

这张表基本覆盖了我在实际使用中反复遇到的高频问题。如果排查过程中有不确定的地方，优先从“这个操作是不是发生在了正确的线程里”开始问，多半能定位到根因。

最后再分享一个我个人的体会：架构图我前前后后画过好几版，最有用的其实不是最终成品，而是画的过程。每次画到跨线程边界时，你都会被逼着去回答“谁在哪个线程里操作什么对象”这个问题，而这些问题恰恰是理解 Muduo 的关键。如果你也想做一份自己的 Muduo 架构总结，建议先别参考现成的图，自己从 EventLoop 开始，一层一层往外画，画完再对照源码修正，收获会比直接看任何总结图都大得多。