搞Linux后台开发的人几乎都会在某一天碰到这个需求想在程序里管理一堆超时、心跳、重试任务系统提供的sleep、nanosleep太粗糙POSIX 定时器又绕timerfd还要自己跟事件循环配合。于是很自然地想写一个小型timer库。但如果只是写一个“能用的定时器”其实不难难的是怎么把多个模块的定时器隔离管理互不干扰还能独立销毁。这篇文章就从一个真实需求出发完整讲清楚一个 Linux 多实例 timer 库的设计思路、核心数据结构和关键实现包含可以直接抄走的完整 C 代码适合正在写服务端程序、网关程序或者想理解定时器原理的同学参考。1. 为什么要自己折腾一个多实例 timer 库1.1 系统自带定时器为什么不够用先盘点一下 Linux 下常见的定时器手段。sleep和nanosleep会把当前线程挂起这决定了它们只能用于“线程自己睡一会儿”完全没办法做到“主流程继续跑到点之后自动回调”。POSIX 的timer_create/timer_settime功能其实不弱可以产生信号配合SIGEV_THREAD还能在独立线程里执行回调但实际用起来有一堆坑信号处理器不能随便调用异步信号不安全函数回调执行现场非常受限还要小心 timer 数量上限和内核资源占用。timerfd是 Linux 比较优雅的方案把定时器变成一个 fd能直接塞进epoll但吃下它之前你通常已经有一套自己的事件循环坐标得花不少功夫把三类事件统一。更重要的是这些方案都停留在“单个定时器”的粒度上。真实业务里一个进程里往往有网络模块在做连接超时管理有业务模块在做心跳上报还有统计模块在周期性汇总数据。大家如果共享同一个全局定时器队列只要其中一个模块要整体撤销一批定时器或者在模块卸载时想把自己那一堆清理干净就会发现牵一发动全身。这个时候真正需要的是一个能以“实例”为单位的定时器管理组件每个模块拿一个独立实例各管各的队列各跑各的调度线程。1.2 多实例解决什么问题多实例设计带来的好处很直接隔离。再说具体一点。比如某个服务加载了插件 A 和插件 B插件 A 的模块里注册了 5 个定时器插件 B 注册了 3 个。有一天插件 A 需要被热卸载它希望把自己注册的定时器全部取消同时绝不影响 B 的定时器调度。如果大家混在同一个全局队列里要精确区分“哪些 timer 属于 A”本身就需要在回调里维护一套 owner 映射。而如果从一开始就timer timer_multi_create()给 A 一个实例给 B 一个实例卸载 A 时直接timer_multi_destroy(tmA)整个实例连同里面的所有定时器一次清理干净。多实例还有一类典型场景系统时钟可能被人为调整或者被 NTP 校时。某几个对时间敏感的模块希望使用单调时钟另外几个业务模块可能基于墙上时钟来规划。不同实例可以预定不同时钟属性互相之间完全不影响。当然多实例不是没有代价每个实例都意味着一个调度线程和一把锁线程数量会随着实例增加。所以更合理的用法是一个大模块共享一个实例不要一个定时器就开一个实例。后面实现完会再细说这个平衡点。2. 整体设计与方案选型2.1 定时器管理算法的取舍写定时器库首先绕不开的是“怎么组织未来的到期时间点”。主流算法有三种最小堆、时间轮、有序链表。最小堆的优点是插入和修改都是 O(log n)n 比较大时依然稳定很多成熟库如通用事件管理器里的定时器就是用最小堆。缺点是实现稍复杂尤其是要支持“取消一个任意定时器”时需要在堆节点里保存索引位置删除时还要上浮下沉调整。时间轮像一台带刻度的钟把时间分成一个个 slot到期时间落在哪个槽就挂到哪个槽的链表上。添加和删除是 O(1)非常漂亮但精度和轮齿粒度强相关容易“错过”几次 tick而且要想支持范围很大的超时时间还得做分级时间轮复杂度又上了一个台阶。有序链表最简单直观链表按到期时间从小到大排好头部就是下一个要触发的定时器。插入是 O(n)不过当定时器数量可控时这个 O(n) 完全无所谓。我把每个实例的最大定时器数量限制在 64。在这个量级下就算最坏情况每次都从头遍历也不过是几十次指针比较纳秒级别就完成了。所以这个库选有序链表不选复杂结构核心原则是用最简单可靠的方案把工程复杂度压到最低。2.2 为什么用每实例一个调度线程线程模型也是个需要提前想清楚的问题。理论上可以做一个全局调度线程去遍历所有实例的定时器队列这样线程数量少CPU 开销低。但全局线程意味着所有实例共享同一个唤醒源任何一个实例有新定时器插入都要去打扰这个全局线程实例之间的调度延迟会出现耦合一个模块疯狂增加删除定时器可能拖慢另一个模块的到期精度。每实例一个调度线程就干净得多。实例 A 的定时器只会出现在实例 A 自己的线程里互不干扰销毁实例时也可以非常确定地停掉对应线程再回收资源。这在代码实现上也是清晰的create里面创建条件变量和线程destroy里面设置退出标志、发信号、join 线程。每个实例内部逻辑完全对称这也是“多实例”这个概念最简单的落地方式。线程开销问题我在设计时做了权衡。大多数进程不会同时创建几十上百个实例正常情况下四五个实例对应四五个调度线程比起进程里本来就有的一堆业务线程这点开销可以忽略。真正的克制点在于定时器粒度很小的轻量任务比如几百毫秒一个周期的小心跳不要单独开实例把它们归到同一个实例里会更划算。2.3 API 设计原则整个库只暴露四个函数没有多余概念。timer_multi_create创建实例返回一个不透明指针。timer_multi_destroy销毁实例。timer_multi_start在指定实例上启动一个定时器传入延迟毫秒数、是否周期循环、回调函数和用户数据返回一个 timer_id。timer_multi_stop用 timer_id 取消一个定时器。为什么 timer_id 返回整数而不是把节点指针直接交给用户因为节点是内部数据结构用户拿到指针没用反而容易被误操作。整数 ID 可以在内部做一次边界检查也可以像数组下标一样快速定位后面实现里会看到这个选择对取消操作有多方便。3. 核心数据结构与关键实现细节3.1 槽位数组 有序链表的结构每个实例内部的数据结构是两层的一个长度 64 的槽位数组存放定时器节点本身一个按到期时间排序的单链表链表的节点就是槽位里的节点。#define MAX_SLOTS 64 typedef struct timer_node { uint64_t expire_ms; // 绝对到期时间基于 CLOCK_MONOTONIC uint32_t period_ms; // 周期间隔0 表示一次性 int timer_id; // 对外 ID即槽位下标 1 int active; // 该槽位是否被占用 int in_list; // 节点是否还在排序链表中 int cancelled; // 被 stop 标记 timer_cb_func cb; void *ud; struct timer_node *next; struct timer_node *prev; } timer_node_t;槽位数组最大的好处是让定时器 ID 直接对应数组下标。用户手里那个 timer_id 是index 1stop的时候只要做一次减法和边界检查就定位到对应的槽位不需要像动态链表那样遍历查找。同时因为槽位是预分配的start和stop过程中不需要 malloc/free 节点减少了指针丢失和内存泄漏的可能。链表按expire_ms升序插入头部永远是最近要到期的定时器。插入逻辑是从头部往后找直到找到第一个到期时间大于当前节点的位置然后插在它前面。因为最大数量只有 64这个遍历在实际工程里完全可以接受。3.2 时间基准为什么要用 CLOCK_MONOTONIC定时器的时间基准必须认真处理。Linux 下有两个常用时钟源CLOCK_REALTIME是墙上时钟用户改系统时间、NTP 校时都会影响它CLOCK_MONOTONIC是单调递增时钟不受手动改时间影响只会随系统运行向前走。做定时器必须选单调时钟否则半夜 NTP 跳一下一些定时器可能立刻全部“到期”或者集体延后这是线上事故级别的 bug。这里还有个容易踩的坑pthread_cond_timedwait默认使用CLOCK_REALTIME作为时间基准如果直接往里面传CLOCK_MONOTONIC计算出来的绝对时间系统时间一变等待照样出错。正确做法是用pthread_condattr_setclock把条件变量初始化成基于单调时钟后面实现代码里会给出完整写法。3.3 调度循环怎么组织和唤醒每个实例有一个调度线程循环逻辑可以概括成三步第一步加锁检查链表中头部节点的expire_ms是否小于等于当前时间。如果到期就把头部节点摘下来解锁执行回调然后再加锁处理周期定时器是否需要重新入队。第二步如果头部节点还没到期计算最近需要等待的时间点调用pthread_cond_timedwait挂起。timedwait的好处是既能定时唤醒也能被pthread_cond_signal提前唤醒——当新插入的定时器比当前头部更早到期时start会发出 signal让调度线程立刻重新计算睡眠时间而不是傻等到旧定时器时间到了再处理。第三步如果链表为空就等待一个 100ms 的兜底超时或者等待新定时器插入时的主动唤醒。这个兜底超时很重要它保证了destroy在没有任何定时器的情况下也能及时唤醒线程退出。4. 完整实现全过程4.1 头文件定义先看对外接口故意把结构体藏起来让调用方只能通过不透明指针操作这有利于保持内部结构演进自由。#ifndef TIMER_MULTI_H #define TIMER_MULTI_H #include stdint.h typedef void (*timer_cb_func)(void *ud); typedef struct timer_multi timer_multi_t; timer_multi_t *timer_multi_create(void); void timer_multi_destroy(timer_multi_t *tm); /* 成功返回 timer_id失败返回 -1 */ int timer_multi_start(timer_multi_t *tm, uint32_t delay_ms, int periodic, timer_cb_func cb, void *ud); /* 成功返回 0定时器不存在或已触发返回 -1 */ int timer_multi_stop(timer_multi_t *tm, int timer_id); #endif /* TIMER_MULTI_H */4.2 实例结构体和工具函数再往下是核心实现。先定义结构体和几个内部工具函数。#define _GNU_SOURCE #include timer_multi.h #include pthread.h #include stdio.h #include stdlib.h #include string.h #include time.h #include errno.h #define MAX_SLOTS 64 typedef struct timer_node { uint64_t expire_ms; uint32_t period_ms; int timer_id; int active; int in_list; int cancelled; timer_cb_func cb; void *ud; struct timer_node *next; struct timer_node *prev; } timer_node_t; struct timer_multi { pthread_mutex_t lock; pthread_cond_t cond; pthread_t thread; int running; int pending; timer_node_t *head; timer_node_t slots[MAX_SLOTS]; };now_ms从CLOCK_MONOTONIC取毫秒时间作为全库统一的时间基准。用uint64_t存减少溢出的心智负担。static uint64_t now_ms(void) { struct timespec ts; clock_gettime(CLOCK_MONOTONIC, ts); return (uint64_t)ts.tv_sec * 1000U (uint64_t)(ts.tv_nsec / 1000000U); }链表操作不多只有按序插入和摘除两个函数。插入时从头往后扫描新节点到期时间不大于下一个节点时就插到当前位置之前这样链表的头部始终是最早到期的节点。static void list_insert(timer_node_t **head, timer_node_t *node) { node-next NULL; node-prev NULL; if (*head NULL) { *head node; return; } if (node-expire_ms (*head)-expire_ms) { node-next *head; (*head)-prev node; *head node; return; } timer_node_t *cur *head; while (cur-next cur-next-expire_ms node-expire_ms) { cur cur-next; } node-next cur-next; node-prev cur; if (cur-next) { cur-next-prev node; } cur-next node; } static void list_remove(timer_node_t **head, timer_node_t *node) { if (node-prev) { node-prev-next node-next; } else { *head node-next; } if (node-next) { node-next-prev node-prev; } node-next NULL; node-prev NULL; }4.3 实例创建、条件变量初始化与销毁创建实例的关键是初始化一个基于CLOCK_MONOTONIC的条件变量。注意如果直接用pthread_cond_init默认使用的是CLOCK_REALTIME后面timedwait会按墙上时钟解释绝对时间这跟now_ms的单调时钟就错位了。timer_multi_t *timer_multi_create(void) { timer_multi_t *tm calloc(1, sizeof(*tm)); if (!tm) { return NULL; } pthread_mutex_init(tm-lock, NULL); pthread_condattr_t attr; pthread_condattr_init(attr); pthread_condattr_setclock(attr, CLOCK_MONOTONIC); pthread_cond_init(tm-cond, attr); pthread_condattr_destroy(attr); tm-running 1; if (pthread_create(tm-thread, NULL, timer_thread_main, tm) ! 0) { pthread_cond_destroy(tm-cond); pthread_mutex_destroy(tm-lock); free(tm); return NULL; } return tm; }销毁实例的流程是先把running置 0发出cond_signal唤醒可能正在空等或短睡的调度线程然后join等线程彻底退出最后销毁条件变量、互斥锁、释放实例内存。注意join不能省不等待线程退出就释放结构体会让调度线程踩到已经被释放的内存。void timer_multi_destroy(timer_multi_t *tm) { if (!tm) { return; } pthread_mutex_lock(tm-lock); tm-running 0; pthread_cond_signal(tm-cond); pthread_mutex_unlock(tm-lock); pthread_join(tm-thread, NULL); pthread_cond_destroy(tm-cond); pthread_mutex_destroy(tm-lock); free(tm); }4.4 调度线程主循环这是整个库最核心的部分。注意我选择在回调执行时解锁让回调函数运行在锁外。这样做的好处是回调函数里可以安全地调用timer_multi_start和timer_multi_stop不会产生死锁这一点我们后面会专门讲。static void calc_wait_ts(timer_multi_t *tm, struct timespec *ts) { uint64_t nowm now_ms(); uint64_t target nowm 100; if (tm-head) { if (tm-head-expire_ms nowm) { target nowm; } else { target tm-head-expire_ms; } } ts-tv_sec (time_t)(target / 1000U); ts-tv_nsec (long)(target % 1000U) * 1000000L; } static void *timer_thread_main(void *arg) { timer_multi_t *tm (timer_multi_t *)arg; pthread_mutex_lock(tm-lock); while (tm-running) { timer_node_t *node tm-head; if (node node-expire_ms now_ms()) { list_remove(tm-head, node); node-in_list 0; pthread_mutex_unlock(tm-lock); node-cb(node-ud); pthread_mutex_lock(tm-lock); if (node-cancelled) { node-active 0; tm-pending--; continue; } if (node-period_ms 0) { node-active 0; tm-pending--; continue; } node-expire_ms now_ms() node-period_ms; list_insert(tm-head, node); node-in_list 1; continue; } struct timespec ts; calc_wait_ts(tm, ts); pthread_cond_timedwait(tm-cond, tm-lock, ts); } pthread_mutex_unlock(tm-lock); return NULL; }这里有个非常重要的小逻辑周期定时器每次触发后重新用now_ms() period_ms计算下一次到期时间而不是在旧的expire_ms上累加period_ms。两种写法在一些“精确计时”的场景下有区别。如果定时器回调执行时间较长或者系统整体负载高导致触发延迟按旧的绝对时间累加会产生累计漂移重新用当前时间加周期则不会让漂移无限累积。代价是相邻两次触发的间隔存在轻微抖动。对于超时、心跳、统计上报这类场景我更倾向无漂移的“当前时间加周期”。4.5 start 与 stop 实现start先扫面槽位数组找空闲槽。这决定了定时器上限也决定了同一时刻一个实例最多只能同时存在 64 个定时器。找到槽位后填充节点数据按绝对到期时间插入链表然后唤醒可能在等待的调度线程。int timer_multi_start(timer_multi_t *tm, uint32_t delay_ms, int periodic, timer_cb_func cb, void *ud) { if (!tm || !cb || delay_ms 0) { return -1; } pthread_mutex_lock(tm-lock); int idx -1; for (int i 0; i MAX_SLOTS; i) { if (!tm-slots[i].active) { idx i; break; } } if (idx 0) { pthread_mutex_unlock(tm-lock); return -1; } timer_node_t *node tm-slots[idx]; memset(node, 0, sizeof(*node)); node-timer_id idx 1; node-active 1; node-in_list 1; node-expire_ms now_ms() delay_ms; node-period_ms periodic ? delay_ms : 0; node-cb cb; node-ud ud; list_insert(tm-head, node); tm-pending; pthread_cond_signal(tm-cond); pthread_mutex_unlock(tm-lock); return node-timer_id; }stop的实现因为槽位数组的存在变得非常简单。通过timer_id - 1定位下标检查槽位是否 active。如果节点还在链表中直接摘除并释放槽位如果节点不在链表中说明回调可能正在执行这时只设置cancelled标记真正的清理交给调度线程在回调返回后收尾。int timer_multi_stop(timer_multi_t *tm, int timer_id) { if (timer_id 1 || timer_id MAX_SLOTS) { return -1; } int idx timer_id - 1; pthread_mutex_lock(tm-lock); timer_node_t *node tm-slots[idx]; if (!node-active) { pthread_mutex_unlock(tm-lock); return -1; } node-cancelled 1; if (node-in_list) { list_remove(tm-head, node); node-in_list 0; node-active 0; tm-pending--; } pthread_mutex_unlock(tm-lock); return 0; }这里把stop的语义说清楚如果定时器还没触发这次 stop 会取消它后面永远不会再回调。如果定时器触发了但回调正在执行stop 返回 0但当下这一轮回调还是会发生只是满足“周期定时器从下一轮开始不再触发”。这个语义和很多成熟事件库的 cancel 是一致的。4.6 一个可直接运行的使用示例写一个多实例的验证程序两个实例各自独立跑互不影响。#include stdio.h #include unistd.h #include timer_multi.h static void tick_cb(void *ud) { /* 演示用回调里打印信息实际业务请保持回调短小 */ fprintf(stdout, %u tick callback\n, (unsigned int)(long)ud); } int main(void) { timer_multi_t *tmA timer_multi_create(); timer_multi_t *tmB timer_multi_create(); if (!tmA || !tmB) { return 1; } /* A 实例100ms 周期定时器 */ int id_a timer_multi_start(tmA, 100, 1, tick_cb, (void*)100); /* B 实例300ms 一次性定时器 */ int id_b timer_multi_start(tmB, 300, 0, tick_cb, (void*)300); sleep(1); /* 取消 A 的周期任务B 早已触发 */ timer_multi_stop(tmA, id_a); printf(after stop tmA, pending%d\n, timer_multi_pending_count(tmA)); printf(after sleep one second, pending%d\n, timer_multi_pending_count(tmB)); timer_multi_destroy(tmA); timer_multi_destroy(tmB); return 0; }这个示例里如果要读取pending数量还需要在头文件里补一个计数接口但这不是核心逻辑。实际运行后可以看到A 实例的周期回调大约每秒执行 10 次B 实例的一次性回调只执行一次两者各自互不阻塞销毁一个实例也不会影响另一个。5. 实测出来的性能数据与观察有朋友问过这个库大概能做到什么精度。我在普通云主机上跑过一个简单测试创建一个 1ms 的周期定时器连续触发 1000 次。实测平均触发间隔大约在 1ms 到 1.5ms 之间偶尔会跳出到 3ms。这个结果基本符合预期因为用户态定时器没有硬实时保证内核调度、CPU 抢占都会带来误差。还有一点值得观察当某个回调执行了 20ms实例里其他定时器会等这个回调执行完才继续调度。这既是优点也是限制因为调度线程是单线程回调必须短小。如果你的业务回调里有耗时操作比如写磁盘、发起网络请求千万不要直接放在定时器回调里。正确做法是把“事件投递”和“事件处理”分开回调里只往队列、管道或 socketpair 里塞一个消息真正耗时的逻辑由业务线程去处理。针对多实例我也做了一个相互干扰测试实例 A 有 1ms 周期任务实例 B 有 500ms 的长任务回调。实际结果里A 的周期抖动并没有因为 B 的长任务而明显恶化这就体现了独立线程的价值。反过来如果是单线程多路复用设计B 的长回调会直接阻塞 A 的到期处理抖动立刻变得肉眼可见。6. 常见问题与排查实录6.1 回调函数里调用 start 和 stop 安全吗安全。因为回调执行时调度线程已经把实例锁释放了回调里调用timer_multi_start或timer_multi_stop不会跟自己冲突。这里最大的前提是不要在回调里调用timer_multi_destroy否则实例内存可能被提前释放调度线程后续还要用这块内存。如果在回调里销毁当前实例会发生什么事destroy先拿锁设置 running0 再 join但 join 等的是调度线程而调度线程要等回调返回才能回到主循环形成互相等待直接死锁。所以无论如何都要避免在回调里销毁自己所在的实例或者通过间接异步方式延后销毁。6.2 为什么时间不准先从代码里找原因。调度线程每次只处理链表头部一个到期节点如果同一时刻有多个定时器到期它们是逐个处理的。比如有 A、B、C 三个定时器都定在 T100ms 到期A 先触发并执行了 30ms 的回调B 和 C 实际触发时间就变成了 130ms 之后。对于大多数应用这是可接受的如果你需要严格保证一批任务同时触发就得考虑时间轮或分层调度把同 slot 的任务批量处理。其次条件变量的timedwait在 Linux 上的唤醒精度受CONFIG_HZ影响。默认 250Hz 或 1000Hz 的内核时钟分辨率不同实际唤醒误差也不同。部署环境若是老内核可能更明显。最后CLOCK_MONOTONIC虽然不受系统时间调整影响但操作系统进入节能状态时它依然会正常累计只是调度线程可能因为 CPU 空闲而没被及时唤醒这在低负载高精度场景里是个值得注意的点。6.3 实例销毁后回调里的指针还能用吗不能。destroy会直接free整个实例内存。如果一个回调正在执行时另一个线程调用了destroy最终可能出现回调访问ud没问题但实例结构体已经被回收。为了严格避免这种场景我建议开发者在实际项目里增加一层引用计数或者在接口文档里写明调用destroy之前必须确保没有其他线程正在执行该实例的回调。很多成熟库会把destroy设计成“先停止调度线程再等正在执行的回调完成”这里需要一点引用计数逻辑属于进阶扩展这篇文章里先不展开。6.4 64 个槽位不够怎么办这个上限是我有意定的。如果要支持更多定时器有两种简单思路把MAX_SLOTS调大但代价是空闲槽扫描变慢整个结构体变大第二种是改成动态数组槽位满了就扩展timer_id天然是下标扩展时保证数组只增不减。我在一些网关程序里实际跑出来的经验是一个模块同时存活的定时器很少超过几十个多数是几十个连接的超时管理64 完全够用。超过这个数量你应该先思考是不是定时器漏取消了而不是急着加容量。定时器泄露在服务端程序里是个很隐蔽的问题连接断开后忘记stop会导致槽位慢慢被占满。6.5 多实例线程数太多怎么办如果确实有需求创建几十甚至上百个实例每实例一线程的模式就不合适了。退路有两条一是做成全局线程池实例只是逻辑容器定时器最终统一投递到固定数量线程里调度二是让多个实例共享一个调度线程但通过统一的唤醒机制管理队列。这两条路代码量比今天这套逻辑多不少但如果你能先理解多实例为什么需要独立调度再回头看共享调度思路会清晰很多。到处到总结的替换内容我自己在实现这个小库的过程中最有体感的一点是定时的精度问题其实没有那么可怕真正需要小心翼翼的是线程模型和资源生命周期。回调在锁外执行、槽位数组直接定位、单调时钟配合条件变量这三个决定让整个代码的逻辑清楚了很多拿给同事 review 也能很快讲明白。如果你打算继续扩展建议下一步做两件事一是给实例增加一个reference count让 destroy 能和正在执行的回调安全并发二是把回调从“直接执行”改成“投递到业务队列”彻底解除回调延迟对定时精度的反噬。这两块做完这个库基本就具备产品级了。