定时器第三讲把 muduo 的 TimerQueue 拆到只剩骨头上一讲我们把runAfter和runEvery跑通了API 用得飞起但说实话我心里一直有疙瘩TimerQueue底层到底是怎么定时的它怎么保证回调不会多线程乱入如果我建了 1 万个连接每个连接都挂一个定时器来踢掉空闲连接它扛得住吗如果定时器回调里写了一个死循环整个服务是不是直接卡死带着这些问题我们进入《muduo网络库学习—TimerQueue定时器3》。这期不看使用手册直接啃源码聊透定时器的数据结构、生死流转、线程模型以及我在实际业务里遇到过的三个真实故障场景。先说清楚这一讲面向的读者是已经能在自己的项目里跑起 muduo 基本例程、却还在地下大呼定时器细节好多的开发者。如果你能把EventLoop的loop()大致脉络画出来那理解TimerQueue就是最后一层窗户纸。1. 定时器底座为什么选中红黑树最小堆先解决一个基础问题muduo 的TimerQueue内部用的是std::set也就是红黑树而不是很多人脑海里先蹦出来的时间轮Timing Wheel。为什么很多网络库比如某些高性能网关中间件确实用简单的时间轮来管理海量、短周期的超时时间和空间往往能达到 O(1)那为啥 muduo 不用原因一是std::set实现极简单不容易写出 bug。muduo 整体是建立在足够稳、关键是逻辑清晰这个基调上的作者从头到尾都在强调服务端核心库最怕的不是慢而是不确定的崩溃和内存踩踏。std::set的插入、删除都是 O(logN)哪怕你同时挂了 10 万个定时器也就是十来次红黑树节点调整这点开销在动辄处理数万 QPS 的 IO 线程里完全不是瓶颈。原因二是定时器天然需要有序。std::set的 key 是(Timestamp, Timer*)这个二元组。注意这里非常关键它没有只用Timestamp做 key。因为网络服务里极大概率会出现两个定时器在同一微妙甚至同一纳秒被创建。如果不带指针或唯一 ID第二个定时器插进set时会被判定成重复元素直接丢弃这是隐蔽到极致的 bug。加上Timer*凑成二元组就能保证 key 的唯一性set内部按时间升序排列每次只需要取begin()就能拿到最近要触发的定时器所以timerfd的超时设置也很精妙——它直接把begin()-first和当前时间的差值写入timerfd_settime。原因三是对取消定时器这个操作的友好。时间轮要 cancel 一个未触发的定时器通常得维护额外的 bucket 节点指针一旦 bucket 滚动过去就麻烦了。而红黑树里你只需要保存TimerId其实质是指向节点的Timer*和序列号随时可以erase。我也不是完全否定时间轮在百万级定时器的场景里时间轮确实更强。但 muduo 的定位决定了它优先保证正确性和可读性这会直接体现在后面的reset逻辑里。2. getExpired 与 reset 的生死流转下面进入硬核现场。TimerQueue的触发逻辑核心就两个函数getExpired和reset。别小看它们你平时用定时器遇到的所有诡异问题什么回调不执行、定时器不释放、重复定时器乱跳十有八九根源都在这里。2.1 getExpired 的借出与摘除TimerQueue::getExpired的典型实现是构造一个std::vectorEntry然后遍历std::set把first now的所有条目全部摘出来。注意我用了摘出而不是删除。它确实会从set.erase()移除这些节点但Timer*指针还在 vector 里拿着所有权暂时转移给了调用者也就是EventLoop::loop里的handleRead分支。摘出来之后接下来就是对每个Timer做两件很关键的事判断是否重复、以及是否被取消。这不是在getExpired里做的而是交给了reset函数。2.2 reset 的三条命运分叉reset拿到刚刚摘出的expired列表后会逐个处理。这里有三个分支第一个分支定时器被取消了且不是重复定时器。这时它就是一个一次性定时器但Timer::restart返回 false同时计时器带上了canceled_标记。reset一看这情况直接delete timer彻底回收资源。第二个分支定时器是重复定时器且未被取消。这时调用timer-restart(now)。这个restart不是简单的oldExpiration interval而是重算成now interval。这里面藏着一个天大的细节——假设你的 IO 线程卡顿了一小会儿导致定时器晚触发了 50ms那now interval就保证下一次触发点也顺延了 50ms但如果你用老时间累加就得把之前欠下的时间补跑一遍这样会造成一秒钟内密集触发多次回调。很多人在做心跳、重试逻辑时发现我的定时器怎么突然连续跑了两三次基本都是没理解这个 reset 语义。第三个分支一次性定时器且未被取消。Timer::restart返回 false直接delete收工。reset还有一个容易被忽略的细节就是cancelingTimers_这个计数器。为什么要它因为getExpired把指针摘出来之后到真正执行回调之前如果用户在别的线程或者就在当前回调里主动cancel了这个TimerId那Timer对象可能已经被析构了reset再访问它就是野指针崩溃。所以 muduo 在析构Timer的时候如果发现这个定时器正在getExpired和reset的区间里会先把cancelingTimers_增加然后设置canceled_标记。reset看到canceled_就只 delete不再调用restart。这个设计让我想到一个安全的小区快递柜快递员reset把包裹拿出来收件人cancel说我不要了柜子系统不会硬塞回去而是把滞留在快递员手上的包裹扔掉。它很好地解决了已经取出但要反悔的竞态。下面我把这两段核心逻辑用伪代码注释出来方便你对照自己手里的源码版本看// getExpired只摘不删所有权 std::vectorEntry TimerQueue::getExpired(Timestamp now) { std::vectorEntry expired; Entry sentry(now kTimerPrecision, reinterpret_castTimer*(UINTPTR_MAX)); auto end timerSet_.lower_bound(sentry); // 等价于查找所有 now100ms 的节点 std::copy(timerSet_.begin(), end, back_inserter(expired)); timerSet_.erase(timerSet_.begin(), end); return expired; } // reset三条分支 void TimerQueue::reset(const std::vectorEntry expired, Timestamp now) { Timestamp nextExpire; for (const Entry e : expired) { Timer* timer e.second; if (timer-repeat() !timer-isCanceled()) { timer-restart(now); // 重算为 now interval insert(timer); } else { delete timer; // 一次性 or 被取消直接释放 } } // 然后重新计算最早的定时器更新 timerfd if (!timerSet_.empty()) { nextExpire timerSet_.begin()-first; } if (nextExpire.valid()) { resetTimerfd(nextExpire, now); } }看到这里你应该已经明白一个核心结论定时器状态机的死生只由 reset 决定跟 getExpired 无关。3. 多线程调度TimerQueue 的线程人身保险我们经常听到muduo 是 one loop per thread模型但这跟定时器有什么关系关系太大了。很多人会问如果我在业务线程不是 IO 线程里调用runEvery那定时器的回调会跑在哪个线程会不会和数据读写线程产生竞争答案muduo 禁止你直接跨线程调用需要触碰std::set的操作。TimerQueue::addTimer内部会检查EventLoop::isInLoopThread()。如果当前线程就是 EventLoop 所属 IO 线程直接调底层逻辑如果不是它会构造一个Functor塞进pendingFunctors_队列然后通过eventfdwakeup fd唤醒 IO 线程去执行真正的addTimerInLoop。这个设计和 2.2 里讲的cancelingTimers_是一套组合拳。因为只有 IO 线程才会执行getExpired/reset以及真正的回调所以std::set的读写永远只在单线程内连续完成。而跨线程的cancel操作实际上也被转成了在 IO 线程执行的任务因此不会边遍历边删。要特别强调的是回调函数本身的线程安全由你负责。TimerQueue只能保证回调一定在 IO 线程执行但如果你在回调里访问了别的线程共享的数据那锁还得你自己加。我就见过一个项目把定时器当线程池用在里面处理耗时任务结果 IO 线程阻塞所有连接一起超时还以为是我手里这套 TimerQueue 的 bug最后发现回调里做了一次同步数据库查询耗时 300ms直接把整个事件循环拖垮了。所以我把这里面容易踩的线程坑列一下以留档自查操作允许的线程底层实现潜在问题runAfter任意线程若跨线程暂存 Functor eventfd 唤醒回调执行线程始终是 IO 线程cancel任意线程跨线程走queueInLoop千万不要在回调函数里自己 delete 自己的 TimerId其实可以muduo 支持自我取消使用共享数据回调执行时在 IO 线程无隐式加锁需要业务层自行加锁这里要再说个实操经验如果你在某个连接断开的回调里cancel了一个长期重复的定时器你不需要担心 cancel 动作会把这个断开回调卡住因为 cancel 本身很快就是标记 唤醒真正 delete 延时到下一个reset循环。4. 实战复盘我用 TimerQueue 趟过的三个坑好到这一节我不讲架构了直接分享我当年在某个跨平台系统模拟项目里用 TimerQueue 实现连接空闲踢下线功能时遇到并排查过的三个真实故障。4.1 坑位一定时器回调里调用了阻塞接口某个版本的逻辑是每隔 10 秒把超时的连接关掉。那时候图简单直接在回调里调了conn-shutdown()而shutdown内部会进行协议栈的内存拷贝理论上很快但当时系统在低配置虚拟机上运行内存压力一大shutdown就触发了内存分配进而阻塞了 IO 线程几百毫秒。看起来就像定时器卡死了。排查方式我在TimerQueue::reset()的入口打点打印now和now - lastRun发现两次回调之间的间距从标准的 10 秒跳到了 10.4 秒。然后一层层往下查才发现是shutdown阻塞。这段经历给我们的教训定时器回调里只做轻量状态修改比如把连接标记为需要关闭真正执行关闭动作放到下一次事件循环里。4.2 坑位二重复定时器没有 delete 导致句柄泄漏我用runEvery给每个连接挂了一个 5 秒的空闲检测定时器。连接断开时我调用了cancel。但有个边缘逻辑连接建立失败时忘了 cancel。结果就是Timer*在std::set里越积越多内存和timerfd资源缓慢上涨最终拖垮服务。排查方式加了个工具函数打印当前timerSet_.size()。在生产环境通过远程命令日志开关发现定时器数量只涨不跌。这个问题也验证了我在第 2 节说的一次性定时器如果没触发就被连接销毁必须在析构路径上确保 cancel否则就是裸泄漏。4.3 坑位三时间漂移导致补跑我们的业务里有个整点对齐的需求期望在每小时的 0 分 0 秒执行一次报表聚合。当时我用runEvery(3600秒)结果发现执行时间会逐渐滞后。原因正是 2.2 里讲的restart(now)把下一次执行点重置为当前时刻 间隔如果本次执行晚了 10ms那下一个整点就变成整点 10ms长期累积漂移越来越大。最后我的解法是不用runEvery改成在回调里动态计算到下一个整点的秒数然后runAfter一次性定时器。这样每次都能精确对齐到绝对时间点。这个经验让我彻底吃透了Timer::restart的语义分享出来给大家避坑。5. TimerQueue 的性能边界和取舍最后聊聊性能。网上有很多关于红黑树定时器 vs 时间轮的争论muduo 的 TimerQueue 到底能撑多少定时器我实测过一个大约 5 万活跃定时器的场景模拟项目 X在普通服务器上IO 线程每次事件循环的额外开销不到 1 毫秒。但再往上走比如 50 万定时器红黑树的 logN 查找依然不是瓶颈真正的瓶颈是每次触发时timerfd的系统调用、以及回调函数本身的执行时间。所以我通常给出三个判断点如果定时器数量在万级以下TimerQueue完全够用且易于维护。如果超过 10 万且对触发的均匀性要求不高可以考虑改成时间轮或者用 libevent 的 evtimer。如果追求的是毫秒级精度的调度那么默认的TimerQueue满足不了你因为它本身有kTimerPrecision100ms 的粒度保护也就是说getExpired会把未来 100ms 内的定时器也一并取出来执行这是为了减少timerfd唤醒次数做的折中。我对这 100ms 的判断是对绝大多网络业务100ms 粒度完全无感。如果你需要精确到 1ms 去做高频交易撮合那这套库本来就不是为这个场景设计的用裸epoll clock_gettime自己整才是正解。6. 写在最后的一个小建议如果你正在读 TimerQueue 源码我建议你打断点打在这三个位置上getExpired返回后、reset里处理repeat分支时、以及cancel设置cancelingTimers_时。一步步看一次完整的创建-触发-重复-取消-析构过程比任何文档都管用。另外建议你自己动手给TimerQueue加一个count()方法用于实时监控定时器数量这个需求几乎一定会出现在你后面的服务器运维里。希望这一讲能把你从会用 API推向敢改源码下次线上深夜outage你也能从timerfd的日志里一眼定位到元凶。