高性能定时器：时间轮算法的工程实践

1. 时间轮的每个格子，用 vector<shared_ptr> 存储任务（shared_ptr 持有任务，控制生命周期）；
2. 当指针走到该格子，我们只需要调用 _wheel[_tick].clear()（清空当前格子）；
3. clear() 会销毁所有 shared_ptr 对象 → 引用计数归零 → TimerTask 对象析构 → 析构函数执行 → 回调函数自动调用；
4. 整个过程，我们不需要手动遍历任务、不需要手动调用回调、不需要手动清理任务，代码极简且不易出错。

五、TimerTask：定时任务的封装（可直接复用）

首先我们封装定时任务本身，每个任务对应一个长连接，核心是存储任务 ID、超时时长、回调函数，以及控制取消状态。

5.1 完整类实现

// 先定义回调函数类型（简化代码）
using TaskFunc = std::function<void()>;
using ReleaseFunc = std::function<void()>;

class TimerTask {
private:
    uint64_t _id; // 任务 ID（通常是连接 ID，唯一标识）
    uint32_t _timeout; // 超时时长（单位：秒，如 30 秒）
    bool _canceled; // 是否被取消（取消后不执行回调）
    TaskFunc _task_cb; // 超时回调（通常是关闭连接）
    ReleaseFunc _release; // 销毁时的清理回调（清理映射表）
public:
    // 构造函数：初始化任务
    TimerTask(uint64_t id, uint32_t delay, const TaskFunc &cb) : _id(id), _timeout(delay), _task_cb(cb), _canceled(false) {}

    // 析构函数：自动执行回调和清理
    ~TimerTask() {
        if (!_canceled) _task_cb(); // 未取消则执行回调
        _release(); // 执行清理逻辑
    }

    // 取消任务（标记为取消，不影响清理）
    void Cancel() { _canceled = true; }

    // 设置清理回调（由 TimerWheel 绑定）
    void SetRelease(const ReleaseFunc &cb) { _release = cb; }

    // 获取基础超时时长（用于刷新任务）
    uint32_t DelayTime() { return _timeout; }
};

5.2 各成员作用（避坑说明）

注意：_release 必须绑定，否则任务销毁后，TimerWheel 中的 _timers 映射表会残留该任务的弱引用，导致野指针和内存泄漏。

六、TimerWheel：时间轮的完整实现（核心代码）

TimerWheel 是整个定时器系统的主体，负责管理时间轮的转动、任务的增删改查、与 epoll 的配合，以及线程安全控制。

6.1 核心数据结构

class TimerWheel {
private:
    using WeakTask = std::weak_ptr<TimerTask>; // 弱引用，仅用于查找
    using PtrTask = std::shared_ptr<TimerTask>; // 强引用，控制生命周期
    int _tick; // 当前指针位置（刻度）
    int _capacity; // 表盘容量（如 60，对应最大 60 秒超时）
    // 时间轮本体：每个刻度对应一个任务列表
    std::vector<std::vector<PtrTask>> _wheel;
    // 任务快速查找表：ID → 弱引用（不影响生命周期，避免内存泄漏）
    std::unordered_map<uint64_t, WeakTask> _timers;
    EventLoop *_loop; // 绑定的事件循环（与 epoll 配合）
    int _timerfd; // Linux 时钟驱动（替代 sleep/poll）
    std::unique_ptr<Channel> _timer_channel; // epoll 事件封装（监听 timerfd）
};

关键设计说明：

• _wheel 用 vector，而非 list：vector 的 clear() 比 list 快，且内存更紧凑，时间轮是'批量插入、批量删除'，vector 更适配；
• _timers 用 weak_ptr：如果用 shared_ptr，会导致任务生命周期被'查找表'和'时间轮'双重持有，即使时间轮清空，任务也不会销毁，造成内存泄漏；weak_ptr 仅用于查找，不影响生命周期；
• _capacity 默认为 60（对应 60 秒），如果需要更长超时，可增大容量或实现多层时间轮（秒轮 + 分轮 + 时轮）。

6.2 添加任务（TimerAdd）

外部调用接口，用于给新连接添加定时器，核心是'创建任务、绑定清理回调、计算刻度、入轮入表'。

// 线程安全接口（外部调用）
void TimerAdd(uint64_t id, uint32_t delay, const TaskFunc &cb) {
    // 投递到 EventLoop 线程执行，保证线程安全
    _loop->RunInLoop([=] { TimerAddInLoop(id, delay, cb); });
}

// 内部实际实现（仅在 EventLoop 线程执行）
void TimerAddInLoop(uint64_t id, uint32_t delay, const TaskFunc &cb) {
    // 1. 创建任务对象（shared_ptr 控制生命周期）
    PtrTask pt(new TimerTask(id, delay, cb));
    // 2. 绑定清理回调：任务销毁时，从_timers 中删除自身
    pt->SetRelease(std::bind(&TimerWheel::RemoveTimer, this, id));
    // 3. 计算目标刻度（避免越界）
    int pos = (_tick + delay) % _capacity;
    // 4. 任务入轮 + 入查找表
    _wheel[pos].push_back(pt);
    _timers[id] = WeakTask(pt);
}

// 清理映射表（由 TimerTask 的析构函数调用）
void RemoveTimer(uint64_t id) {
    _timers.erase(id);
}

6.3 刷新任务（TimerRefresh）——高频核心操作

这是最常用的操作：当长连接收到数据（有活动）时，需要重置超时时间。传统实现是'删除旧任务、添加新任务'，复杂度 O(1) 但逻辑繁琐，我的实现更巧妙。

// 线程安全接口（外部调用）
void TimerRefresh(uint64_t id) {
    _loop->RunInLoop([=] { TimerRefreshInLoop(id); });
}

// 内部实际实现（仅在 EventLoop 线程执行）
void TimerRefreshInLoop(uint64_t id) {
    // 1. 查找任务（弱引用转换为强引用）
    auto it = _timers.find(id);
    if (it == _timers.end()) { return; } // 任务不存在（可能已超时销毁）
    PtrTask pt = it->second.lock(); // weak_ptr → shared_ptr（成功则任务还存在）
    if (!pt) { _timers.erase(it); return; }
    // 2. 计算新的目标刻度（复用基础超时时长）
    int delay = pt->DelayTime();
    int pos = (_tick + delay) % _capacity;
    // 3. 关键操作：再放一份到新刻度（引用计数 +1）
    _wheel[pos].push_back(pt);
}

核心原理：

刷新任务，本质是'延长任务的生命周期'，而非'删除旧任务、添加新任务'：

• 刷新前：_wheel[旧刻度] 有一个 shared_ptr，任务引用计数 = 1；
• 刷新后：_wheel[旧刻度] 和 _wheel[新刻度] 各有一个 shared_ptr，引用计数 = 2；
• 指针走到旧刻度：clear() 销毁旧刻度的 shared_ptr，引用计数 = 1，任务不销毁；
• 指针走到新刻度：clear() 销毁新刻度的 shared_ptr，引用计数 = 0，任务销毁，回调执行。

这个设计避免了'先删后加'的复杂逻辑，无需查找旧任务在哪个刻度，直接添加新引用即可，效率更高、代码更简洁。

6.4 取消任务（TimerCancel）

当连接主动关闭时，需要取消对应的定时器（避免超时后再次执行关闭回调）。取消的核心是'标记取消'，而非'删除任务'。

// 线程安全接口（外部调用）
void TimerCancel(uint64_t id) {
    _loop->RunInLoop([=] { TimerCancelInLoop(id); });
}

// 内部实际实现（仅在 EventLoop 线程执行）
void TimerCancelInLoop(uint64_t id) {
    auto it = _timers.find(id);
    if (it == _timers.end()) { return; }
    PtrTask pt = it->second.lock();
    if (pt) { pt->Cancel(); } // 仅标记为取消，不删除任务
}

为什么不直接删除任务？

因为任务可能存在于时间轮的某个刻度中，查找并删除任务需要遍历刻度，复杂度 O(n)，效率低。而'标记取消'是 O(1) 操作，任务会在时间轮流转到对应刻度后，被 clear() 销毁，只是析构时不执行回调而已，清理逻辑仍会执行。

6.5 时间驱动：timerfd + epoll（核心心跳）

时间轮需要一个'心跳'来驱动指针前进，不能用 sleep（会阻塞线程），也不能用 poll（效率低）。Linux 提供的 timerfd 是最佳选择——它可以被 epoll 监听，每隔指定时间变为可读，完美融入 EventLoop 事件循环。

6.5.1 创建 timerfd

static int CreateTimerfd() {
    // 创建 timerfd，CLOCK_MONOTONIC：系统启动后流逝的时间（不受系统时间修改影响）
    int timerfd = timerfd_create(CLOCK_MONOTONIC, 0);
    if (timerfd < 0) {
        // 错误处理（实际工程中需添加日志）
        perror("timerfd_create error");
        exit(EXIT_FAILURE);
    }
    // 设置定时周期：首次 1 秒后触发，后续每 1 秒触发一次
    struct itimerspec itime;
    memset(&itime, 0, sizeof(itime));
    itime.it_value.tv_sec = 1; // 第一次超时：1 秒后
    itime.it_value.tv_nsec = 0;
    itime.it_interval.tv_sec = 1; // 之后每隔 1 秒触发一次（周期）
    itime.it_interval.tv_nsec = 0;
    // 应用定时设置
    timerfd_settime(timerfd, 0, &itime, NULL);
    return timerfd;
}

6.5.2 处理超时事件（驱动指针转动）

当 timerfd 变为可读时，说明时间到了，我们需要读取超时次数（避免事件堆积），然后驱动指针转动，执行超时任务。

// 读取 timerfd 的超时次数（自上次读取后，超时了几次）
int ReadTimefd() {
    uint64_t times;
    ssize_t n = read(_timerfd, &times, sizeof(times));
    if (n != sizeof(times)) {
        // 错误处理（实际工程中需添加日志）
        perror("read timerfd error");
        return 0;
    }
    return static_cast<int>(times);
}

// timerfd 可读事件回调（由 EventLoop 触发）
void OnTime() {
    int times = ReadTimefd(); // 获取累积超时次数
    // 批量处理所有超时（避免 epoll 阻塞导致的时间堆积）
    for (int i = 0; i < times; i++) {
        RunTimerTask();
    }
}

// 驱动指针转动，执行当前刻度的超时任务
void RunTimerTask() {
    // 指针前进一格（循环转动，避免越界）
    _tick = (_tick + 1) % _capacity;
    // 清空当前刻度：销毁所有 shared_ptr → 任务析构 → 执行回调
    _wheel[_tick].clear();
}

注意：必须读取'超时次数'并批量处理。因为 epoll 可能因为处理其他事件（如读写事件）耗时过久，导致 timerfd 超时了多次（比如阻塞了 3 秒，timerfd 就超时了 3 次），如果只处理一次，会导致时间轮指针滞后，任务超时不准确。

七、和 EventLoop 的配合（线程安全保障）

网络框架中，EventLoop 通常是单线程的，而定时器的操作（增/刷/取消）可能来自不同线程：

• 添加任务：可能在主线程（新连接建立时）；
• 刷新任务：可能在 IO 线程（收到客户端数据时）；
• 取消任务：可能在 IO 线程（连接主动关闭时）。

如果多个线程同时操作 _wheel 和 _timers，会导致数据竞争（崩溃、野指针等问题）。

解决方案：统一在 Loop 线程执行

所有定时器操作，都通过 EventLoop 的 RunInLoop 接口，投递到 EventLoop 单线程执行，天然避免数据竞争，实现线程安全。

这也是为什么我们在 TimerAdd、TimerRefresh、TimerCancel 三个接口中，都加了 _loop->RunInLoop(…) 的封装——外部线程调用时，会把任务投递到 Loop 线程，由 Loop 线程统一执行实际的操作（TimerAddInLoop 等）。

RunInLoop 的实现逻辑很简单（这里不展开）：如果当前线程是 Loop 线程，直接执行；如果不是，把任务放到任务队列，由 Loop 线程循环取出执行。

八、完整工作流程（串联所有逻辑）

用一个长连接的完整生命周期，串联整个定时器的工作流程，让你彻底明白每一步的作用：

8.1 连接建立（添加定时器）

// 新连接创建成功后，添加 30 秒超时定时器
timer_wheel->TimerAdd(conn_id, 30, [conn] { conn->Shutdown(); }); // 超时回调：关闭连接

此时：_wheel[(_tick+30)%60] 中添加了该任务的 shared_ptr，_timers 中添加了该任务的 weak_ptr。

8.2 收到数据（刷新定时器）

// 连接收到客户端数据，刷新定时器（重置为 30 秒超时）
timer_wheel->TimerRefresh(conn_id);

此时：任务的引用计数 +1，_wheel[(_tick+30)%60] 中再添加一份该任务的 shared_ptr。

8.3 正常超时（无活动）

1. 时间流逝，_tick 逐步递增，直到走到任务所在的刻度；
2. OnTime 被触发，读取超时次数（假设为 1），调用 RunTimerTask()；
3. _tick 前进一格，_wheel[_tick].clear()，销毁该格子的 shared_ptr；
4. 任务引用计数归零，TimerTask 析构，执行回调 conn->Shutdown()，关闭连接；
5. 析构函数调用 _release()，从 _timers 中删除该任务的记录。

8.4 有活动（超时延长）

1. _tick=0：添加任务到 _wheel[30]，引用计数=1；
2. _tick=10：收到数据，刷新任务，添加到 _wheel[40]，引用计数=2；
3. _tick=30：clear() _wheel[30]，引用计数=1，任务不销毁；
4. _tick=40：clear() _wheel[40]，引用计数=0，任务销毁，回调执行（若仍无活动）。

九、工程落地细节与避坑总结

9.1 为什么 _capacity 选 60？

60 秒是长连接超时的常用值（大部分场景下，30~60 秒无活动就可以关闭连接），选 60 可以让单轮时间轮覆盖大部分场景。

如果业务需要更长的超时（比如 5 分钟），有两种方案：

• 简单方案：增大 _capacity（如 300，对应 5 分钟）；
• 优雅方案：实现多层时间轮（秒轮 60 格、分轮 60 格、时轮 24 格），适合超时间隔跨度大的场景。

9.2 为什么用 vector 而非 list？

时间轮的任务操作是'批量插入、批量删除'（每次刷新批量插入，每次超时批量删除），vector 的 clear() 是连续内存操作，比 list 的节点遍历删除快得多；而且 vector 的内存更紧凑，缓存命中率更高，性能更优。

9.3 内存开销（是否可控？）

假设我们有 10 万连接，每个连接一个定时器：

• _wheel：60 个 vector，共 10 万个 shared_ptr；
• _timers：10 万个 weak_ptr；
• 每个智能指针（64 位系统）约 16 字节，总内存约 3.2 MB（10 万×16×2），完全可控。

即使是 100 万连接，总内存也只有 32 MB，对服务器来说几乎可以忽略。

9.4 常见坑点汇总

• 坑 1：_timers 用 shared_ptr 导致内存泄漏 → 解决方案：用 weak_ptr；
• 坑 2：忘记绑定 _release 回调 → 解决方案：创建任务时必须 SetRelease，清理 _timers；
• 坑 3：不处理 timerfd 的累积超时 → 解决方案：读取超时次数，批量执行 RunTimerTask；
• 坑 4：多线程操作时间轮 → 解决方案：所有操作通过 RunInLoop 投递到 Loop 线程；
• 坑 5：刷新任务时'先删后加' → 解决方案：直接添加新引用，利用引用计数延长生命周期。

十、总结

这套基于时间轮的定时器，核心优势是'高性能、易落地、线程安全'，完美适配长连接网络服务的场景。它的核心设计思想，其实就是把几个简单的技术点（时间轮、智能指针、timerfd、EventLoop）优雅地结合起来，用最少的代码解决工程上的复杂问题。

最后，用一张表总结核心设计点，方便你快速回顾：

时间轮不是一个新概念，但工程落地的细节，只有实际写过、踩过坑，才能真正掌握。希望这篇文章能帮你跳过定时器的那些坑，顺利把网络框架的定时器层落地。