1. 先弄清楚 Acceptor 在网络库里的生态位很多人读 muduo 源码第一眼会挑EventLoop、Poller、Channel这种“骨架级”类下手读了两天还停在事件分发机制里出不来。我的建议正好反过来先挑一个Acceptor这样的小类完整走一遍它从构造、监听、触发回调到把连接交出去的生命周期反而能把整个 Reactor 模型的运行节奏串起来。Acceptor这个类只有两个文件头文件加实现文件加起来一百多行但它是每个 TCP 服务端连接的第一个入口。可以这样理解整个网络库的结构TcpServer是业务层面的门面它负责创建监听器、管理连接池、分配 IO 线程而Acceptor就是那个真正坐在门口接客的人手里攥着监听 socket耳朵贴在门上听内核的通知。EventLoop、Channel、Poller负责“监听 fd 什么时候可读”这件事但“可读之后真的去调用 accept、拿到新连接的 fd 和对端地址再转交给上层”这是Acceptor的专职。所以它在代码里的生态位非常清晰一个TcpServer只创建一个AcceptorAcceptor绑定到某一个EventLoop而且是“从一而终”的不允许被别的线程乱调它内部持有一个监听 socket以及一个用来观察这个 socket 可读事件的Channel一旦监听 socket 可读说明内核的 accept 队列里至少有一个已完成三次握手的新连接Acceptor::handleRead()被调用执行 accept拿到connfd和peerAddr最后通过newConnectionCallback_回调把connfd交给上层去创建TcpConnection。这套流程里最关键的设计约束是“监听 socket 必须是非阻塞的”。原因很简单handleRead()跑在事件循环线程里如果 accept 会阻塞一旦某个瞬间突然有大量连接同时挤进来整个事件循环都会被卡住其他已建立连接的 IO 事件全都得不到处理。muduo 在Acceptor构造函数里用createNonblockingOrDie()创建监听 fd这一步把“非阻塞 执行时关闭”两个属性一次性定死从根上杜绝了 accept 阻塞事件循环的可能。另一个值得注意的边界是Acceptor不负责也不应该负责业务逻辑。它既不处理客户端数据也不管理连接生命周期后的读写状态。它的职责只有三件监听、accept、转交。你可以在它身上看清一个优秀网络库划分职责的方式——小类不贪心只把自己那一亩三分地种好。2. 读头文件先把“对外契约”看透再碰实现源码解析最容易犯的错是一上来就钻进.cc的实现细节结果被变量飞来飞去搞得头晕。正确顺序是先读.h把类的对外契约和内部状态摸清楚。muduo 的Acceptor.h是一个很标准的范例先看完整版本// Acceptor.h #pragma once #include functional #include boost/noncopyable.hpp #include Channel.h #include Socket.h namespace muduo { namespace net { class EventLoop; class InetAddress; class Acceptor : boost::noncopyable { public: typedef std::functionvoid (int sockfd, const InetAddress) NewConnectionCallback; Acceptor(EventLoop* loop, const InetAddress listenAddr, bool reuseport); ~Acceptor(); void setNewConnectionCallback(const NewConnectionCallback cb) { newConnectionCallback_ cb; } bool listening() const { return listening_; } void listen(); private: void handleRead(); EventLoop* loop_; Socket acceptSocket_; Channel acceptChannel_; NewConnectionCallback newConnectionCallback_; bool listening_; int idleFd_; }; } // namespace net } // namespace muduo2.1 构造函数参数里的三个信号构造函数签名是Acceptor(EventLoop* loop, const InetAddress listenAddr, bool reuseport)三个参数都有讲究。第一个参数传EventLoop*表示这个Acceptor依附于哪个事件循环。在 muduo 里IO 对象和线程的绑定关系是硬约束Acceptor的所有公开方法内部都会调用loop_-assertInLoopThread()来保证这一点。这不是形式主义的防御而是防止有人在别的线程里偷偷调用listen()或触发回调导致事件循环内部的Channel状态和 poller 的实际注册情况不一致。这种线程约束是 muduo 这类“one loop per thread”模型的核心习惯也是它比某些跨线程到处加锁的网络库更容易读懂的的原因。第二个参数是监听地址。平时写服务端程序最常见的是传InetAddress(port)这样会绑定到本机所有可用 IP 的对应端口上也可以显式指定 IP比如只允许内网网卡接受连接。在构造函数里完成 bind意味着Acceptor对象一创建出来端口就已经被占住了不会有“对象建好了但还没绑定”的中间状态。第三个参数reuseport是开关SO_REUSEPORT的选项。这里要说一下它和SO_REUSEADDR的区别SO_REUSEADDR解决的是“端口被 TIME_WAIT 连接占用导致重启时 bind 失败”的问题SO_REUSEPORT解决的是“多个进程或线程可以 bind 同一个 IP:端口由内核做负载均衡”的问题。muduo 把reuseport做成构造参数而不是硬编码打开是因为这个特性在不同操作系统上的行为差异比较大而且一旦启用多进程模型的调试成本会上升。默认情况下开不开取决于上层TcpServer怎么传。2.2 成员变量暗藏的设计信号再看成员变量这几个字段的顺序和类型几乎把类的运行方式都交代了成员类型作用loop_EventLoop*所属事件循环用于线程断言acceptSocket_Socket监听 socket 的 RAII 封装负责 fd 生命周期acceptChannel_Channel把监听 fd 挂到 poller 上的桥梁负责事件分发newConnectionCallback_std::functionaccept 成功后的上行回调listening_bool是否已经开始监听idleFd_int预占用的空闲 fd用于处理 EMFILE 问题一眼就能看出这个类没有直接保存裸 fd而是通过Socket和Channel两个封装类来管理监听 socket。Socket管的是 fd 的打开和关闭析构时自动 close杜绝了忘记关 fd 的泄漏Channel管的是事件注册它知道自己的 fd 在哪个EventLoop的 poller 里也知道可读时该回调谁。这种组合方式比“自己捏着 int fd 到处传”干净得多。还有一个细节值得玩味NewConnectionCallback的签名是void (int sockfd, const InetAddress)直接把裸 fd 传上去。为什么不封装一个Socket对象再传因为 fd 的所有权在这里发生了转移Acceptoraccept 之后这个 fd 就归上层TcpServer了上层会创建TcpConnection来接管它。如果传给上层的还是一个带着析构函数的Socket对象反而容易让人误会所有权还留在Acceptor这边。头文件里还有一个对外方法setNewConnectionCallback()它只是简单赋值。但请注意这个函数没有线程保护所以正确的使用顺序一定是在调用listen()之前把回调设置好。muduo 的作者在TcpServer里就是这么做的构造函数里创建Acceptor紧接着注册新连接回调最后才由TcpServer::start()触发listen()。把这个顺序读懂了你就知道为什么哪怕回调是空的Acceptor也不会崩——它的handleRead()里设计了“回调为空就直接 close”的兜底逻辑这一点后面还会展开。3. 实现拆解从构造函数到 handleRead 的三段式生命周期Acceptor的实现代码不长但每一段都有值得展开的设计理由。我按生命周期顺序拆成三段来看构造、listen、handleRead。3.1 构造函数四件事的顺序不能乱实现代码大致长这样Acceptor::Acceptor(EventLoop* loop, const InetAddress listenAddr, bool reuseport) : loop_(loop), acceptSocket_(sockets::createNonblockingOrDie()), acceptChannel_(loop, acceptSocket_.fd()), listening_(false), idleFd_(::open(/dev/null, O_RDONLY | O_CLOEXEC)) { assert(idleFd_ 0); acceptSocket_.setReuseAddr(true); acceptSocket_.setReusePort(reuseport); acceptSocket_.bindAddress(listenAddr); acceptChannel_.setReadCallback(std::bind(Acceptor::handleRead, this)); }构造函数一共做了四件事第一创建监听 socket并确保它是非阻塞的。在 Linux 上这一步通常是通过socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK | SOCK_CLOEXEC, 0)完成的。SOCK_NONBLOCK保证了 accept 不会阻塞SOCK_CLOEXEC保证 fork 后执行其他程序时不会意外继承这个 fd。这两个属性在 fd 创建时就定死比创建后再用fcntl设置要安全得多因为中间不会出现短暂“竞态窗口”。第二创建Channel并绑定到监听 fd。注意Channel在构造时还不会向 poller 注册任何事件它只是记录了“我是谁的 fd我的回调是什么”。这种“先创建对象、后启用事件”的分离给上层留出了足够的初始化时间。第三立即打开/dev/null占住一个空闲 fd存到idleFd_。这一步很多第一次读源码的人会忽略但它其实是一个重要的防御机制万一进程的文件描述符数量达到上限Acceptor可以靠这个预占的 fd 临时腾挪出一次 accept 的机会。后面我会单独用一整节来讲它。第四设置 socket 选项并 bind。先setReuseAddr(true)避免服务重启时因为旧连接的 TIME_WAIT 状态导致 bind 失败然后按构造参数决定是否setReusePort(reuseport)最后bindAddress(listenAddr)。到这里端口已经绑上但还没开始监听所以此时还不会有新连接进来。这四件事的顺序不是随便写的必须先有 fd才能设置 fd 的选项必须先 bind后面 listen 才有意义必须把Channel建好、回调绑定好后面事件真正触发时才能正确转发。muduo 把所有这些准备工作都塞进构造函数使得Acceptor对象一旦构造完毕就处于“就差 listen 一步”的待命状态。3.2 listen()内核开始排队事件循环开始关心listen()的实现也很短void Acceptor::listen() { loop_-assertInLoopThread(); listening_ true; acceptSocket_.listen(); acceptChannel_.enableReading(); }这里有两步操作顺序有讲究先真正调用内核的listen()再让Channel启用读事件。先listen()的意义是让内核开始接受 TCP 三次握手但新连接不会立刻被处理而是排队在内核的 accept 队列里队列长度由listen()的 backlog 参数决定。等到acceptChannel_.enableReading()执行完监听 fd 才被注册到EventLoop的 poller 上。之后只要内核 accept 队列非空poller 就会认为这个 fd “可读”于是事件循环会在下一次迭代里调用handleRead()。为什么不颠倒顺序先 enableReading 再 listen从逻辑上看颠倒也不会出灾难性事故但先 listen 后开启读事件可以保证“poller 开始关注这个 fd 的时候内核已经真正进入监听状态了”避免中间出现“事件注册了但内核还没准备好”的怪异窗口。而且在 muduo 的设计哲学里listen()本身就是在明确宣布“我现在要开始接客了”这个状态转变必须由底层 socket 先完成再由上层的 Channel 对外广播。这里还带出一个经常被问到的问题为什么Acceptor的线程约束这么严格连listen()都要assertInLoopThread()因为acceptChannel_是和某个EventLoop绑定的而EventLoop内部维护的 poller 状态不是线程安全的。如果从别的线程调用listen()去enableReading()极可能和事件循环正在进行的 poll/pollfds 修改产生冲突。muduo 的解决方式不是加锁而是从设计上禁止跨线程调用——哪个线程负责这个 loop就由哪个线程来操作这个 loop 管辖的对象。这是“one loop per thread”模型的常见姿态读源码时适应它写代码时也能少踩一半坑。3.3 handleRead()新连接的“最短处理路径”监听 socket 可读之后EventLoop会回调Channel里绑定的函数也就是Acceptor::handleRead()void Acceptor::handleRead() { loop_-assertInLoopThread(); InetAddress peerAddr; int connfd acceptSocket_.accept(peerAddr); if (connfd 0) { if (newConnectionCallback_) { newConnectionCallback_(connfd, peerAddr); } else { sockets::close(connfd); } } else { int savedErrno errno; LOG_SYSERR Acceptor::handleRead; if (savedErrno EMFILE) { ::close(idleFd_); idleFd_ ::accept(acceptSocket_.fd(), NULL, NULL); ::close(idleFd_); idleFd_ ::open(/dev/null, O_RDONLY | O_CLOEXEC); } } }正常情况下路径非常短accept 拿到connfd同时通过InetAddress peerAddr获得对端地址然后直接丢给newConnectionCallback_。这个回调在 muduo 的TcpServer里会负责创建TcpConnection、设置好连接的各种回调、把它加入事件循环从此这个连接的后续读写就由另外的类去管了Acceptor和它再无关系。有两个细节值得理解。一是“只 accept 一次”还是“循环 accept 到 EAGAIN”的问题。muduo 在这里默认只 accept 一次这是有意为之因为监听 fd 工作在电平触发模式下如果 accept 队列里还有连接poller 会再次触发可读事件根本不会丢。相比之下循环 accept 到 EAGAIN 会一次性处理完队列里的所有连接好处是吞吐更高坏处是如果某个瞬间连接风暴特别猛一个事件循环迭代可能被 accept 独占很久饿死其他连接的数据处理。muduo 的取舍是“每次事件都处理但每次只处理一个”既简单又平均。这一点后面我会在第五部分展开对比。二是回调为空的兜底逻辑。newConnectionCallback_是std::function如果上层忘了注册accept 成功后直接 close 这个连接既不让 fd 泄漏也不让连接悬挂。实际场景里TcpServer总是在构造Acceptor后立刻注册回调但防御性代码仍然要覆盖这种边界情况。读这种工业级源码最应该学的就是这种“即使你误用我我也不崩”的兜底习惯。4. EMFILE 防御机制idleFd 与文件描述符耗尽的现场复盘handleRead()里最容易被忽略、但最值得单独拎出来讲的是EMFILE分支。我第一次读这段代码时也跳过去了后来压测踩了坑才意识到这一小段代码在连接数接近上限时能救整个服务。4.1 为什么会走到 EMFILE 这个分支EMFILE的意思是“进程的文件描述符数量已经达到系统上限”。每个进程能打开的 fd 数是有限的默认软限制通常是 1024 或更大一些但这 1024 个并不是全都留给连接的——监听 socket 本身占一个epoll 实例占一个日志文件占一个定时器 fd 占一个如果程序里还开了管道、信号 fd、线程间的 eventfd这些都在偷偷消耗 fd 配额。也就是说当活跃连接数量还远没到上限时其他杂七杂八的 fd 可能已经把配额吃光了。最典型的故障场景是服务端撑到某个连接数某个瞬间客户端发起大量新连接内核 accept 队列瞬间堆满。Acceptor检测到监听 fd 可读调用accept()但这时进程已经拿不出新的 fd 了于是accept()返回 -1errno被置为EMFILE。如果这段代码不做任何处理会发生什么新连接已经完成了三次握手挂在内核的 accept 队列里没人取走。客户端此时还傻乎乎地以为自己连上了服务端实际上服务端根本看不见它、不会为它创建TcpConnection。对于客户端来说这个连接既不成功也不失败表现为“连上了但没反应”。如果上层有超时重连逻辑客户端会不断重连每次重连又继续把 accept 队列堆满最终形成恶性循环。4.2 idleFd 的完整工作流程muduo 的应对方式很巧妙既然问题在于“没有可用的 fd 来 accept”那就提前留一个能随时腾出来的 fd 备用。构造函数里打开/dev/null作为idleFd_相当于进程手里始终捏着一个“临时避难所”。当 accept 失败且errno EMFILE时事件循环执行下面四个动作关闭idleFd_立刻空出一个 fd 名额调用::accept(acceptSocket_.fd(), NULL, NULL)这时因为已经腾出了一个名额accept 必然成功拿到这个新连接的 fd立刻close这个新连接的 fd重新打开/dev/null作为新的idleFd_恢复“避难所”。这样做的效果是虽然进程的 fd 依然处于耗尽状态但每次 accept 失败后至少有一次机会把一个新连接从内核 accept 队列里取出来。由于接出来之后马上关闭客户端会立刻收到连接被关闭的信号而不是一直处于“看似建立却毫无响应”的悬空状态。这比不断堆积 backlog 要健康得多也能减轻客户端无意义重连对系统造成的压力。为什么选/dev/null而不是开一个普通文件原因很简单/dev/null不需要实际写数据、不会增长、不占磁盘打开成本也低。加O_CLOEXEC是为了防止 fork 后执行子进程时把这个 fd 意外带过去这是 Linux 上长期实践总结出来的标准姿势。4.3 这个机制能完全防住连接风暴吗直说结论idleFd不是银弹它只能缓解“fd 耗尽导致 accept 失效”的最痛部分不能解决 fd 配额本身不够的问题。真正要防住连接风暴还是得靠监控、fd 配额调优、连接上限控制这些外部手段。但从源码设计的角度看这一个idleFd_字段和 EMFILE 分支体现的是一种“再失败也要给系统留出回旋余地”的思路。很多自研网络库在 accept 出错后只打一行日志就完了结果连接全堆在 backlog 里服务表现为假死。而 muduo 用几十行代码在极限情况下依然保持“接一个、关一个、继续服务”的节奏这给上层业务争取到了响应降级或告警的时间。我在自己的压测实验里复现过这个场景把进程的ulimit -n临时降到 200然后持续创建连接用系统调用跟踪工具观察能清楚看到Acceptor在 fd 耗尽后反复执行“close idleFd - accept - close - open idleFd”的循环。没有这段代码时accept 队列会越积越长连接成功率直线下降有了这段代码服务端至少能保持“不接受任何新连接”的明确状态而不是“假装接受但什么也不做”。5. 从 Acceptor 延伸出去新连接的去向与几个实战体会把Acceptor读完之后自然会有个问题newConnectionCallback_被触发后那个connfd到底去哪了只有追到这一步才算真正理解Acceptor在网络库里的位置。5.1 新连接回调从 Acceptor 到 TcpConnection在 muduo 的TcpServer里构造Acceptor后注册的回调内容大致如下根据新连接是否启用多线程模型从EventLoopThreadPool里挑一个合适的EventLoop用connfd和peerAddr构造一个新的TcpConnection对象设置这个TcpConnection的各种回调比如消息回调、写完成回调、连接建立/关闭回调把TcpConnection注册到选定的EventLoop上让它开始处理这个连接的读写事件。这里要提醒一点newConnectionCallback_的执行上下文仍然是Acceptor所在的事件循环线程。也就是说创建TcpConnection这件事本身是在 IO 线程里完成的所以回调里的工作必须足够轻量。如果上层在回调里做了磁盘读写、数据库查询或者大量解析计算就会直接堵住事件循环影响所有连接。正确的做法是回调里只做对象创建和注册真正的业务逻辑交给后续的消息回调去处理。追到这里你会发现Acceptor的职责边界非常干净它不判断“这个连接该归哪个线程”那是由上层TcpServer的线程池策略决定的它也不参与连接对象的生命周期管理那是由TcpConnection自己负责的。Acceptor只保证一件事只要内核告诉我“有新连接”我就把新连接的 fd 和地址完整地递给上层绝不在自己这里多做一步。5.2 一次 accept 与循环 accept 的取舍对比我在前面已经提过 muduo 默认“一次事件只 accept 一次”这里展开对比一下它和“循环 accept 到 EAGAIN”的差异也是面试里高频出现的讨论点。策略优点缺点适用场景一次事件 accept 一次逻辑简单单次事件处理耗时短公平性高连接突发量大时每个连接多等一次事件循环迭代绝大多数通用服务端循环 accept 到 EAGAIN一次事件把 backlog 清空突发吞吐高若 accept 数量不受控会长时间占用事件循环对单次突发连接量有明确预期的场景muduo 选前者还有一个重要原因监听 fd 是电平触发模式accept 队列只要非空poller 就会反复触发可读事件。所以哪怕一次只 accept 一个也不会出现“连接已经来了但没人处理”的情况只是把这些连接的处理分散到了后续几次事件循环迭代里。这样做让事件循环的单次迭代耗时更可控不容易出现某个连接的数据处理被突发连接拖到超时的情况。我见过有些自研网络库照抄 muduo 的思路但内部把监听 fd 设成了边缘触发模式这就出了问题——边缘触发只在状态变化时通知一次如果 accept 一次之后没把队列清空下一次通知就遥遥无期了。所以“accept 一次”的策略和事件触发模式是绑定的照搬代码时一定要连配置一起搬。5.3 顺着 Acceptor 读源码的几个实用技巧最后分享几个我自己读这段源码时的实操经验。第一读小文件优先于读大文件。Acceptor.h和Acceptor.cc加起来一百多行半小时就能吃透但它能帮你建立“监听 socket 是怎么进入事件循环”的完整心智模型。先有小类的清晰认知再去看TcpServer这种几百行的大类就不会迷路。第二盯住 fd 的所有权转移。Acceptor里的acceptSocket_自己管 fd 的释放但 accept 出来的connfd是“裸 int”一旦通过回调传出去所有权就移交给了上层。读代码时画一条线createNonblockingOrDie创建 fd -Socket持有并负责关闭 - accept 产生新 fd - 回调转交 -TcpConnection接管。这条线不断整个连接生命周期就顺下来了。第三把assertInLoopThread()当成阅读路标。每次看到这个断言就说明后面的代码是某个事件循环线程独有的。它能帮你快速判断哪些操作是线程敏感的将来自己写多线程网络代码时也会下意识地去声明“这个函数必须在哪个线程调用”而不是靠注释提醒自己。第四模拟极端场景验证理解。比如把ulimit -n调小、用上百个客户端同时重连去观察idleFd_分支到底有没有生效。源码读十遍不如动手压一次很多细节是在极端场景里才看得清的。我自己的习惯是读完Acceptor之后马上接着读TcpServer里设置newConnectionCallback_的代码再读TcpConnection的构造函数。这一条线索走完一个连接从“内核三次握手完成”到“进入 IO 循环开始收发数据”的完整链路就全通了。再回头去看EventLoop、Poller、Channel这些底层机制时你会发现它们都是在为这条链路上的对象服务理解起来会轻松一大截。 
长河君 · 2026/10/21 9:02:38 · 阅读 1.2k muduo Acceptor源码深度解析：从非阻塞监听连接到EMFILE防御机制
1. 先弄清楚 Acceptor 在网络库里的生态位很多人读 muduo 源码第一眼会挑EventLoop、Poller、Channel这种“骨架级”类下手读了两天还停在事件分发机制里出不来。我的建议正好反过来先挑一个Acceptor这样的小类完整走一遍它从构造、监听、触发回调到把连接交出去的生命周期反而能把整个 Reactor 模型的运行节奏串起来。Acceptor这个类只有两个文件头文件加实现文件加起来一百多行但它是每个 TCP 服务端连接的第一个入口。可以这样理解整个网络库的结构TcpServer是业务层面的门面它负责创建监听器、管理连接池、分配 IO 线程而Acceptor就是那个真正坐在门口接客的人手里攥着监听 socket耳朵贴在门上听内核的通知。EventLoop、Channel、Poller负责“监听 fd 什么时候可读”这件事但“可读之后真的去调用 accept、拿到新连接的 fd 和对端地址再转交给上层”这是Acceptor的专职。所以它在代码里的生态位非常清晰一个TcpServer只创建一个AcceptorAcceptor绑定到某一个EventLoop而且是“从一而终”的不允许被别的线程乱调它内部持有一个监听 socket以及一个用来观察这个 socket 可读事件的Channel一旦监听 socket 可读说明内核的 accept 队列里至少有一个已完成三次握手的新连接Acceptor::handleRead()被调用执行 accept拿到connfd和peerAddr最后通过newConnectionCallback_回调把connfd交给上层去创建TcpConnection。这套流程里最关键的设计约束是“监听 socket 必须是非阻塞的”。原因很简单handleRead()跑在事件循环线程里如果 accept 会阻塞一旦某个瞬间突然有大量连接同时挤进来整个事件循环都会被卡住其他已建立连接的 IO 事件全都得不到处理。muduo 在Acceptor构造函数里用createNonblockingOrDie()创建监听 fd这一步把“非阻塞 执行时关闭”两个属性一次性定死从根上杜绝了 accept 阻塞事件循环的可能。另一个值得注意的边界是Acceptor不负责也不应该负责业务逻辑。它既不处理客户端数据也不管理连接生命周期后的读写状态。它的职责只有三件监听、accept、转交。你可以在它身上看清一个优秀网络库划分职责的方式——小类不贪心只把自己那一亩三分地种好。2. 读头文件先把“对外契约”看透再碰实现源码解析最容易犯的错是一上来就钻进.cc的实现细节结果被变量飞来飞去搞得头晕。正确顺序是先读.h把类的对外契约和内部状态摸清楚。muduo 的Acceptor.h是一个很标准的范例先看完整版本// Acceptor.h #pragma once #include functional #include boost/noncopyable.hpp #include Channel.h #include Socket.h namespace muduo { namespace net { class EventLoop; class InetAddress; class Acceptor : boost::noncopyable { public: typedef std::functionvoid (int sockfd, const InetAddress) NewConnectionCallback; Acceptor(EventLoop* loop, const InetAddress listenAddr, bool reuseport); ~Acceptor(); void setNewConnectionCallback(const NewConnectionCallback cb) { newConnectionCallback_ cb; } bool listening() const { return listening_; } void listen(); private: void handleRead(); EventLoop* loop_; Socket acceptSocket_; Channel acceptChannel_; NewConnectionCallback newConnectionCallback_; bool listening_; int idleFd_; }; } // namespace net } // namespace muduo2.1 构造函数参数里的三个信号构造函数签名是Acceptor(EventLoop* loop, const InetAddress listenAddr, bool reuseport)三个参数都有讲究。第一个参数传EventLoop*表示这个Acceptor依附于哪个事件循环。在 muduo 里IO 对象和线程的绑定关系是硬约束Acceptor的所有公开方法内部都会调用loop_-assertInLoopThread()来保证这一点。这不是形式主义的防御而是防止有人在别的线程里偷偷调用listen()或触发回调导致事件循环内部的Channel状态和 poller 的实际注册情况不一致。这种线程约束是 muduo 这类“one loop per thread”模型的核心习惯也是它比某些跨线程到处加锁的网络库更容易读懂的的原因。第二个参数是监听地址。平时写服务端程序最常见的是传InetAddress(port)这样会绑定到本机所有可用 IP 的对应端口上也可以显式指定 IP比如只允许内网网卡接受连接。在构造函数里完成 bind意味着Acceptor对象一创建出来端口就已经被占住了不会有“对象建好了但还没绑定”的中间状态。第三个参数reuseport是开关SO_REUSEPORT的选项。这里要说一下它和SO_REUSEADDR的区别SO_REUSEADDR解决的是“端口被 TIME_WAIT 连接占用导致重启时 bind 失败”的问题SO_REUSEPORT解决的是“多个进程或线程可以 bind 同一个 IP:端口由内核做负载均衡”的问题。muduo 把reuseport做成构造参数而不是硬编码打开是因为这个特性在不同操作系统上的行为差异比较大而且一旦启用多进程模型的调试成本会上升。默认情况下开不开取决于上层TcpServer怎么传。2.2 成员变量暗藏的设计信号再看成员变量这几个字段的顺序和类型几乎把类的运行方式都交代了成员类型作用loop_EventLoop*所属事件循环用于线程断言acceptSocket_Socket监听 socket 的 RAII 封装负责 fd 生命周期acceptChannel_Channel把监听 fd 挂到 poller 上的桥梁负责事件分发newConnectionCallback_std::functionaccept 成功后的上行回调listening_bool是否已经开始监听idleFd_int预占用的空闲 fd用于处理 EMFILE 问题一眼就能看出这个类没有直接保存裸 fd而是通过Socket和Channel两个封装类来管理监听 socket。Socket管的是 fd 的打开和关闭析构时自动 close杜绝了忘记关 fd 的泄漏Channel管的是事件注册它知道自己的 fd 在哪个EventLoop的 poller 里也知道可读时该回调谁。这种组合方式比“自己捏着 int fd 到处传”干净得多。还有一个细节值得玩味NewConnectionCallback的签名是void (int sockfd, const InetAddress)直接把裸 fd 传上去。为什么不封装一个Socket对象再传因为 fd 的所有权在这里发生了转移Acceptoraccept 之后这个 fd 就归上层TcpServer了上层会创建TcpConnection来接管它。如果传给上层的还是一个带着析构函数的Socket对象反而容易让人误会所有权还留在Acceptor这边。头文件里还有一个对外方法setNewConnectionCallback()它只是简单赋值。但请注意这个函数没有线程保护所以正确的使用顺序一定是在调用listen()之前把回调设置好。muduo 的作者在TcpServer里就是这么做的构造函数里创建Acceptor紧接着注册新连接回调最后才由TcpServer::start()触发listen()。把这个顺序读懂了你就知道为什么哪怕回调是空的Acceptor也不会崩——它的handleRead()里设计了“回调为空就直接 close”的兜底逻辑这一点后面还会展开。3. 实现拆解从构造函数到 handleRead 的三段式生命周期Acceptor的实现代码不长但每一段都有值得展开的设计理由。我按生命周期顺序拆成三段来看构造、listen、handleRead。3.1 构造函数四件事的顺序不能乱实现代码大致长这样Acceptor::Acceptor(EventLoop* loop, const InetAddress listenAddr, bool reuseport) : loop_(loop), acceptSocket_(sockets::createNonblockingOrDie()), acceptChannel_(loop, acceptSocket_.fd()), listening_(false), idleFd_(::open(/dev/null, O_RDONLY | O_CLOEXEC)) { assert(idleFd_ 0); acceptSocket_.setReuseAddr(true); acceptSocket_.setReusePort(reuseport); acceptSocket_.bindAddress(listenAddr); acceptChannel_.setReadCallback(std::bind(Acceptor::handleRead, this)); }构造函数一共做了四件事第一创建监听 socket并确保它是非阻塞的。在 Linux 上这一步通常是通过socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK | SOCK_CLOEXEC, 0)完成的。SOCK_NONBLOCK保证了 accept 不会阻塞SOCK_CLOEXEC保证 fork 后执行其他程序时不会意外继承这个 fd。这两个属性在 fd 创建时就定死比创建后再用fcntl设置要安全得多因为中间不会出现短暂“竞态窗口”。第二创建Channel并绑定到监听 fd。注意Channel在构造时还不会向 poller 注册任何事件它只是记录了“我是谁的 fd我的回调是什么”。这种“先创建对象、后启用事件”的分离给上层留出了足够的初始化时间。第三立即打开/dev/null占住一个空闲 fd存到idleFd_。这一步很多第一次读源码的人会忽略但它其实是一个重要的防御机制万一进程的文件描述符数量达到上限Acceptor可以靠这个预占的 fd 临时腾挪出一次 accept 的机会。后面我会单独用一整节来讲它。第四设置 socket 选项并 bind。先setReuseAddr(true)避免服务重启时因为旧连接的 TIME_WAIT 状态导致 bind 失败然后按构造参数决定是否setReusePort(reuseport)最后bindAddress(listenAddr)。到这里端口已经绑上但还没开始监听所以此时还不会有新连接进来。这四件事的顺序不是随便写的必须先有 fd才能设置 fd 的选项必须先 bind后面 listen 才有意义必须把Channel建好、回调绑定好后面事件真正触发时才能正确转发。muduo 把所有这些准备工作都塞进构造函数使得Acceptor对象一旦构造完毕就处于“就差 listen 一步”的待命状态。3.2 listen()内核开始排队事件循环开始关心listen()的实现也很短void Acceptor::listen() { loop_-assertInLoopThread(); listening_ true; acceptSocket_.listen(); acceptChannel_.enableReading(); }这里有两步操作顺序有讲究先真正调用内核的listen()再让Channel启用读事件。先listen()的意义是让内核开始接受 TCP 三次握手但新连接不会立刻被处理而是排队在内核的 accept 队列里队列长度由listen()的 backlog 参数决定。等到acceptChannel_.enableReading()执行完监听 fd 才被注册到EventLoop的 poller 上。之后只要内核 accept 队列非空poller 就会认为这个 fd “可读”于是事件循环会在下一次迭代里调用handleRead()。为什么不颠倒顺序先 enableReading 再 listen从逻辑上看颠倒也不会出灾难性事故但先 listen 后开启读事件可以保证“poller 开始关注这个 fd 的时候内核已经真正进入监听状态了”避免中间出现“事件注册了但内核还没准备好”的怪异窗口。而且在 muduo 的设计哲学里listen()本身就是在明确宣布“我现在要开始接客了”这个状态转变必须由底层 socket 先完成再由上层的 Channel 对外广播。这里还带出一个经常被问到的问题为什么Acceptor的线程约束这么严格连listen()都要assertInLoopThread()因为acceptChannel_是和某个EventLoop绑定的而EventLoop内部维护的 poller 状态不是线程安全的。如果从别的线程调用listen()去enableReading()极可能和事件循环正在进行的 poll/pollfds 修改产生冲突。muduo 的解决方式不是加锁而是从设计上禁止跨线程调用——哪个线程负责这个 loop就由哪个线程来操作这个 loop 管辖的对象。这是“one loop per thread”模型的常见姿态读源码时适应它写代码时也能少踩一半坑。3.3 handleRead()新连接的“最短处理路径”监听 socket 可读之后EventLoop会回调Channel里绑定的函数也就是Acceptor::handleRead()void Acceptor::handleRead() { loop_-assertInLoopThread(); InetAddress peerAddr; int connfd acceptSocket_.accept(peerAddr); if (connfd 0) { if (newConnectionCallback_) { newConnectionCallback_(connfd, peerAddr); } else { sockets::close(connfd); } } else { int savedErrno errno; LOG_SYSERR Acceptor::handleRead; if (savedErrno EMFILE) { ::close(idleFd_); idleFd_ ::accept(acceptSocket_.fd(), NULL, NULL); ::close(idleFd_); idleFd_ ::open(/dev/null, O_RDONLY | O_CLOEXEC); } } }正常情况下路径非常短accept 拿到connfd同时通过InetAddress peerAddr获得对端地址然后直接丢给newConnectionCallback_。这个回调在 muduo 的TcpServer里会负责创建TcpConnection、设置好连接的各种回调、把它加入事件循环从此这个连接的后续读写就由另外的类去管了Acceptor和它再无关系。有两个细节值得理解。一是“只 accept 一次”还是“循环 accept 到 EAGAIN”的问题。muduo 在这里默认只 accept 一次这是有意为之因为监听 fd 工作在电平触发模式下如果 accept 队列里还有连接poller 会再次触发可读事件根本不会丢。相比之下循环 accept 到 EAGAIN 会一次性处理完队列里的所有连接好处是吞吐更高坏处是如果某个瞬间连接风暴特别猛一个事件循环迭代可能被 accept 独占很久饿死其他连接的数据处理。muduo 的取舍是“每次事件都处理但每次只处理一个”既简单又平均。这一点后面我会在第五部分展开对比。二是回调为空的兜底逻辑。newConnectionCallback_是std::function如果上层忘了注册accept 成功后直接 close 这个连接既不让 fd 泄漏也不让连接悬挂。实际场景里TcpServer总是在构造Acceptor后立刻注册回调但防御性代码仍然要覆盖这种边界情况。读这种工业级源码最应该学的就是这种“即使你误用我我也不崩”的兜底习惯。4. EMFILE 防御机制idleFd 与文件描述符耗尽的现场复盘handleRead()里最容易被忽略、但最值得单独拎出来讲的是EMFILE分支。我第一次读这段代码时也跳过去了后来压测踩了坑才意识到这一小段代码在连接数接近上限时能救整个服务。4.1 为什么会走到 EMFILE 这个分支EMFILE的意思是“进程的文件描述符数量已经达到系统上限”。每个进程能打开的 fd 数是有限的默认软限制通常是 1024 或更大一些但这 1024 个并不是全都留给连接的——监听 socket 本身占一个epoll 实例占一个日志文件占一个定时器 fd 占一个如果程序里还开了管道、信号 fd、线程间的 eventfd这些都在偷偷消耗 fd 配额。也就是说当活跃连接数量还远没到上限时其他杂七杂八的 fd 可能已经把配额吃光了。最典型的故障场景是服务端撑到某个连接数某个瞬间客户端发起大量新连接内核 accept 队列瞬间堆满。Acceptor检测到监听 fd 可读调用accept()但这时进程已经拿不出新的 fd 了于是accept()返回 -1errno被置为EMFILE。如果这段代码不做任何处理会发生什么新连接已经完成了三次握手挂在内核的 accept 队列里没人取走。客户端此时还傻乎乎地以为自己连上了服务端实际上服务端根本看不见它、不会为它创建TcpConnection。对于客户端来说这个连接既不成功也不失败表现为“连上了但没反应”。如果上层有超时重连逻辑客户端会不断重连每次重连又继续把 accept 队列堆满最终形成恶性循环。4.2 idleFd 的完整工作流程muduo 的应对方式很巧妙既然问题在于“没有可用的 fd 来 accept”那就提前留一个能随时腾出来的 fd 备用。构造函数里打开/dev/null作为idleFd_相当于进程手里始终捏着一个“临时避难所”。当 accept 失败且errno EMFILE时事件循环执行下面四个动作关闭idleFd_立刻空出一个 fd 名额调用::accept(acceptSocket_.fd(), NULL, NULL)这时因为已经腾出了一个名额accept 必然成功拿到这个新连接的 fd立刻close这个新连接的 fd重新打开/dev/null作为新的idleFd_恢复“避难所”。这样做的效果是虽然进程的 fd 依然处于耗尽状态但每次 accept 失败后至少有一次机会把一个新连接从内核 accept 队列里取出来。由于接出来之后马上关闭客户端会立刻收到连接被关闭的信号而不是一直处于“看似建立却毫无响应”的悬空状态。这比不断堆积 backlog 要健康得多也能减轻客户端无意义重连对系统造成的压力。为什么选/dev/null而不是开一个普通文件原因很简单/dev/null不需要实际写数据、不会增长、不占磁盘打开成本也低。加O_CLOEXEC是为了防止 fork 后执行子进程时把这个 fd 意外带过去这是 Linux 上长期实践总结出来的标准姿势。4.3 这个机制能完全防住连接风暴吗直说结论idleFd不是银弹它只能缓解“fd 耗尽导致 accept 失效”的最痛部分不能解决 fd 配额本身不够的问题。真正要防住连接风暴还是得靠监控、fd 配额调优、连接上限控制这些外部手段。但从源码设计的角度看这一个idleFd_字段和 EMFILE 分支体现的是一种“再失败也要给系统留出回旋余地”的思路。很多自研网络库在 accept 出错后只打一行日志就完了结果连接全堆在 backlog 里服务表现为假死。而 muduo 用几十行代码在极限情况下依然保持“接一个、关一个、继续服务”的节奏这给上层业务争取到了响应降级或告警的时间。我在自己的压测实验里复现过这个场景把进程的ulimit -n临时降到 200然后持续创建连接用系统调用跟踪工具观察能清楚看到Acceptor在 fd 耗尽后反复执行“close idleFd - accept - close - open idleFd”的循环。没有这段代码时accept 队列会越积越长连接成功率直线下降有了这段代码服务端至少能保持“不接受任何新连接”的明确状态而不是“假装接受但什么也不做”。5. 从 Acceptor 延伸出去新连接的去向与几个实战体会把Acceptor读完之后自然会有个问题newConnectionCallback_被触发后那个connfd到底去哪了只有追到这一步才算真正理解Acceptor在网络库里的位置。5.1 新连接回调从 Acceptor 到 TcpConnection在 muduo 的TcpServer里构造Acceptor后注册的回调内容大致如下根据新连接是否启用多线程模型从EventLoopThreadPool里挑一个合适的EventLoop用connfd和peerAddr构造一个新的TcpConnection对象设置这个TcpConnection的各种回调比如消息回调、写完成回调、连接建立/关闭回调把TcpConnection注册到选定的EventLoop上让它开始处理这个连接的读写事件。这里要提醒一点newConnectionCallback_的执行上下文仍然是Acceptor所在的事件循环线程。也就是说创建TcpConnection这件事本身是在 IO 线程里完成的所以回调里的工作必须足够轻量。如果上层在回调里做了磁盘读写、数据库查询或者大量解析计算就会直接堵住事件循环影响所有连接。正确的做法是回调里只做对象创建和注册真正的业务逻辑交给后续的消息回调去处理。追到这里你会发现Acceptor的职责边界非常干净它不判断“这个连接该归哪个线程”那是由上层TcpServer的线程池策略决定的它也不参与连接对象的生命周期管理那是由TcpConnection自己负责的。Acceptor只保证一件事只要内核告诉我“有新连接”我就把新连接的 fd 和地址完整地递给上层绝不在自己这里多做一步。5.2 一次 accept 与循环 accept 的取舍对比我在前面已经提过 muduo 默认“一次事件只 accept 一次”这里展开对比一下它和“循环 accept 到 EAGAIN”的差异也是面试里高频出现的讨论点。策略优点缺点适用场景一次事件 accept 一次逻辑简单单次事件处理耗时短公平性高连接突发量大时每个连接多等一次事件循环迭代绝大多数通用服务端循环 accept 到 EAGAIN一次事件把 backlog 清空突发吞吐高若 accept 数量不受控会长时间占用事件循环对单次突发连接量有明确预期的场景muduo 选前者还有一个重要原因监听 fd 是电平触发模式accept 队列只要非空poller 就会反复触发可读事件。所以哪怕一次只 accept 一个也不会出现“连接已经来了但没人处理”的情况只是把这些连接的处理分散到了后续几次事件循环迭代里。这样做让事件循环的单次迭代耗时更可控不容易出现某个连接的数据处理被突发连接拖到超时的情况。我见过有些自研网络库照抄 muduo 的思路但内部把监听 fd 设成了边缘触发模式这就出了问题——边缘触发只在状态变化时通知一次如果 accept 一次之后没把队列清空下一次通知就遥遥无期了。所以“accept 一次”的策略和事件触发模式是绑定的照搬代码时一定要连配置一起搬。5.3 顺着 Acceptor 读源码的几个实用技巧最后分享几个我自己读这段源码时的实操经验。第一读小文件优先于读大文件。Acceptor.h和Acceptor.cc加起来一百多行半小时就能吃透但它能帮你建立“监听 socket 是怎么进入事件循环”的完整心智模型。先有小类的清晰认知再去看TcpServer这种几百行的大类就不会迷路。第二盯住 fd 的所有权转移。Acceptor里的acceptSocket_自己管 fd 的释放但 accept 出来的connfd是“裸 int”一旦通过回调传出去所有权就移交给了上层。读代码时画一条线createNonblockingOrDie创建 fd -Socket持有并负责关闭 - accept 产生新 fd - 回调转交 -TcpConnection接管。这条线不断整个连接生命周期就顺下来了。第三把assertInLoopThread()当成阅读路标。每次看到这个断言就说明后面的代码是某个事件循环线程独有的。它能帮你快速判断哪些操作是线程敏感的将来自己写多线程网络代码时也会下意识地去声明“这个函数必须在哪个线程调用”而不是靠注释提醒自己。第四模拟极端场景验证理解。比如把ulimit -n调小、用上百个客户端同时重连去观察idleFd_分支到底有没有生效。源码读十遍不如动手压一次很多细节是在极端场景里才看得清的。我自己的习惯是读完Acceptor之后马上接着读TcpServer里设置newConnectionCallback_的代码再读TcpConnection的构造函数。这一条线索走完一个连接从“内核三次握手完成”到“进入 IO 循环开始收发数据”的完整链路就全通了。再回头去看EventLoop、Poller、Channel这些底层机制时你会发现它们都是在为这条链路上的对象服务理解起来会轻松一大截。