1. 项目概述一个跨平台的C/C定时器实现最近在整理自己的代码工具箱翻出来一个几年前写的、至今还在多个项目里服役的C/C定时器程序。这个东西看着简单不就是一个“到点执行任务”的功能嘛但真要自己从零写一个稳定、高效、跨平台的里头的门道还真不少。网上很多demo要么是Windows的SetTimer要么是Linux的timer_create代码绑死在特定系统上想移植一下就得大动干戈。我这个实现的目标很明确用纯C/C标准库和少量平台API封装一个统一的定时器接口让你在Windows、Linux、macOS上都能用同一套代码并且支持同时管理成百上千个定时任务。这个程序的核心价值在哪里对于做网络服务、游戏服务器、嵌入式中间件或者任何需要后台调度任务的开发者来说一个可靠的定时器组件就像是心脏的起搏器。心跳检测、数据缓存过期、定时统计报表、延迟任务触发……这些场景都离不开它。我提供的源码和demo就是把这个“起搏器”的完整设计图纸和组装说明书都给你你不仅能直接拿去用更能看懂每一行代码为什么这么写以后根据自己业务需求修改起来也心里有底。2. 核心设计思路与架构拆解2.1 为什么不用现成的库或系统API首先得回答这个问题市面上有libevent、Boost.Asio的定时器操作系统也提供了API为什么还要自己造轮子原因有几个。第一是依赖和体积很多项目尤其是嵌入式或对安装包体积敏感的场景引入一个庞大的第三方库成本太高。第二是可控性自己实现的定时器每一个行为、每一处超时误差你都清清楚楚出了问题能精准定位。第三是学习价值亲手实现一遍是理解多线程、时间轮、回调机制等核心概念的最佳途径。我的设计目标是“最小核心最大灵活”。整个定时器模块就两个核心文件timer.h和timer.c如果是C项目可以提供timer.hpp和timer.cpp的版本。对外只暴露几个简洁的接口创建定时器、启动定时器、停止定时器、销毁定时器。内部则封装了所有平台差异和复杂的调度逻辑。2.2 核心架构时间轮算法与线程模型定时器的实现算法常见的有好几种简单链表、最小堆、时间轮。我选择了时间轮算法。你可以把它想象成一个老式的钟表表盘分成很多格子比如60格代表60秒每个格子挂着一个链表链表里的任务就是要在那一“秒”执行的任务。秒针每跳一格就检查当前格子里的所有任务执行到期的。这种算法在定时任务数量多、但精度要求不是极端高比如毫秒级的场景下添加、删除定时器的平均时间复杂度是O(1)效率非常高。线程模型上我采用了经典的单线程调度外部多线程触发模型。具体来说我创建了一个独立的“调度线程”它唯一的工作就是死循环检查时间轮判断哪些任务到期了。一旦任务到期调度线程并不会直接执行这个任务因为任务函数里可能有阻塞操作会拖垮整个定时器而是将这个到期任务放入一个“任务队列”。另外我可以创建多个“工作线程”来从这个队列里取出任务并执行。这样做的好处是将“任务调度”和“任务执行”解耦调度线程永远不会被阻塞保证了定时触发的准时性而工作线程池可以灵活扩展处理耗时的任务。注意这里有一个关键取舍。纯单线程定时器调度和执行在同一线程实现简单但一个耗时任务会延迟后续所有定时任务。而“调度与执行分离”的模型虽然复杂些但稳定性高得多。对于绝大多数应用我强烈推荐后者。3. 源码关键模块深度解析3.1 数据结构定义如何描述一个定时任务一切从数据结构开始。一个定时任务至少需要包含哪些信息看下面的核心结构体以C为例typedef struct timer_task_s { uint64_t id; // 定时器唯一ID int rotation; // 时间轮需要转多少圈后触发 int time_slot; // 位于时间轮的哪个槽 void (*callback)(void* arg); // 到期回调函数 void *user_data; // 回调函数参数 struct timer_task_s *next; // 链表下一个任务 } timer_task_t;id: 每个定时器的唯一标识。用于后续停止或删除特定定时器。这里使用一个自增的64位整数理论上很难溢出。rotation time_slot: 这是时间轮算法的核心。假设我们的时间轮有60个槽每100毫秒指针移动一格。那么一个5500毫秒5.5秒后的任务rotation 5秒 / 60*0.1秒/圈的整数部分time_slot (当前槽位 55) % 60。rotation表示这个任务还要等待时间轮转多少整圈才到期。callback user_data: 定义了定时器到期后要做什么。这是一个函数指针配合一个万能指针参数提供了极大的灵活性。你可以传一个统计函数来打印日志也可以传一个网络函数去发送心跳包。next: 因为每个时间轮槽位可能挂多个任务所以用链表串起来。3.2 时间轮的管理与推进机制时间轮的主体结构如下typedef struct timer_wheel_s { int tick_ms; // 每格代表的毫秒数时间精度 int slot_num; // 时间轮总槽数 int current_slot; // 当前指针指向的槽 pthread_mutex_t lock; // 保护任务链表的锁 timer_task_t *slots[TIMER_WHEEL_SIZE]; // 任务槽数组 volatile int running; // 调度线程运行标志 pthread_t scheduler_tid; // 调度线程ID task_queue_t *task_queue; // 到期任务队列 } timer_wheel_t;调度线程的主循环是这个组件的发动机其简化逻辑如下static void* scheduler_thread_func(void *arg) { timer_wheel_t *wheel (timer_wheel_t*)arg; while (wheel-running) { // 1. 睡眠一个tick的间隔如100ms usleep(wheel-tick_ms * 1000); pthread_mutex_lock(wheel-lock); // 2. 指针移动到下一个槽 wheel-current_slot (wheel-current_slot 1) % wheel-slot_num; // 3. 处理当前槽的所有任务 timer_task_t *task wheel-slots[wheel-current_slot]; timer_task_t *prev NULL; while (task ! NULL) { timer_task_t *next task-next; if (task-rotation 0) { // 轮数未减到0说明还没到期只需减少轮数 task-rotation--; prev task; } else { // 轮数为0任务到期从链表移除 if (prev NULL) { wheel-slots[wheel-current_slot] next; } else { prev-next next; } // 将到期任务放入执行队列由工作线程处理 task_queue_push(wheel-task_queue, task); } task next; } pthread_mutex_unlock(wheel-lock); } return NULL; }这个循环清晰地展示了时间轮的运转睡眠固定间隔 → 移动指针 → 检查并处理到期任务。锁pthread_mutex_t在这里至关重要因为它保护任务链表防止在添加任务和调度线程遍历任务时发生竞争。3.3 跨平台的时间获取与睡眠这是实现跨平台特性的关键难点。在Linux/macOS上我们习惯用gettimeofday或clock_gettime获取高精度时间用usleep或nanosleep进行线程睡眠。但在Windows上这些函数要么没有要么精度不够。我的解决方案是使用条件编译// timer_platform.h #ifdef _WIN32 #include windows.h #define get_current_time_ms() (GetTickCount64()) #define thread_sleep_ms(ms) Sleep(ms) #else #include sys/time.h #include unistd.h static inline uint64_t get_current_time_ms() { struct timeval tv; gettimeofday(tv, NULL); return (uint64_t)tv.tv_sec * 1000 tv.tv_usec / 1000; } #define thread_sleep_ms(ms) usleep((ms) * 1000) #endif对于更高精度的时间需求比如需要纳秒级定时或测量在Linux上可以启用clock_gettime(CLOCK_MONOTONIC, ...)在Windows上则可以使用QueryPerformanceCounter。在提供的源码中我默认使用了毫秒级精度的实现这在绝大多数业务场景如秒级、百毫秒级定时中已经完全够用并且保证了最好的兼容性。实操心得跨平台代码的编译测试一定要早做、勤做。我建议在写代码时就在旁边打开Windows的Visual Studio和Linux的GCC终端每写一个平台相关函数就立刻在两个环境下编译一下。避免把所有代码写完后再做移植那时堆积的问题会让你非常头疼。4. 接口设计与使用Demo详解4.1 简洁的API接口我设计了四个核心API力求简单直观// 初始化定时器管理器并启动调度线程 timer_manager_t* timer_init(int tick_ms, int slot_num, int worker_thread_num); // 添加一个定时任务 uint64_t timer_add(timer_manager_t *mgr, uint64_t delay_ms, void (*cb)(void*), void *arg, int is_periodic); // 取消一个定时任务 int timer_cancel(timer_manager_t *mgr, uint64_t timer_id); // 销毁定时器管理器释放所有资源 void timer_cleanup(timer_manager_t *mgr);timer_init: 这是入口。tick_ms决定了定时器的最小精度比如设为100那么所有定时器的到期时间都会对齐到100ms的整数倍。slot_num是时间轮的槽数两者共同决定了定时器的最大间隔。例如tick_ms100,slot_num60则最大定时间隔是100*606000ms。worker_thread_num指定处理到期任务的工作线程数量设为0则使用默认值比如CPU核心数。timer_add: 添加定时任务的核心。delay_ms是延迟时间cb和arg是回调函数及其参数。is_periodic标志位非常有用如果设为1那么这个任务在执行完后会自动重新添加到定时器中从而实现周期性执行比如每5秒一次的心跳。函数返回一个唯一的timer_id用于后续管理。timer_cancel: 通过timer_id取消一个尚未触发的定时任务。这里有一个细节如果任务已经到期并被放入执行队列但还没有被工作线程执行我们依然可以尝试从队列中移除它。这需要任务队列支持按ID删除操作在源码中我实现了这个特性。timer_cleanup: 负责优雅地停止调度线程和工作线程等待当前正在执行的任务完成然后释放所有内存。这是一个好习惯避免资源泄漏。4.2 完整Demo程序拆解光说不练假把式我附带的demo程序展示了三种典型用法Demo 1: 单次定时与周期定时#include timer_manager.h #include stdio.h void print_hello(void *arg) { char *name (char*)arg; printf([%lld] Hello, %s!\n, get_current_time_ms(), name); } void print_count(void *arg) { static int count 0; printf([%lld] Periodic task count: %d\n, get_current_time_ms(), count); } int main() { // 初始化精度100ms时间轮60格2个工作线程 timer_manager_t *mgr timer_init(100, 60, 2); // 添加一个3秒后执行的单次任务 uint64_t id1 timer_add(mgr, 3000, print_hello, Alice, 0); // 添加一个每秒执行的周期性任务 uint64_t id2 timer_add(mgr, 1000, print_count, NULL, 1); // 主线程等待10秒观察定时任务执行 sleep(10); // 取消周期任务 timer_cancel(mgr, id2); printf(Periodic task cancelled.\n); // 再等2秒后退出 sleep(2); timer_cleanup(mgr); return 0; }这个demo演示了最基本的使用流程。你会看到“Hello, Alice!”在3秒后打印一次而“Periodic task count”则会每秒打印一次直到第10秒被取消。Demo 2: 定时器在简单网络心跳中的应用这个demo模拟了一个客户端连接管理器需要定时检查所有连接是否健康。typedef struct { int fd; // 模拟的网络套接字 uint64_t last_active_time; } connection_t; void check_connection_heartbeat(void *arg) { connection_t *conn (connection_t*)arg; uint64_t now get_current_time_ms(); if (now - conn-last_active_time 5000) { // 5秒无活动 printf(Connection fd%d timeout, closing.\n, conn-fd); // 这里实际应调用 close(conn-fd) 并释放conn } else { // 连接健康可以发送一个心跳包 // send_heartbeat_packet(conn-fd); } } // 模拟一个新连接建立 void setup_connection(timer_manager_t *mgr, int fd) { connection_t *conn malloc(sizeof(connection_t)); conn-fd fd; conn-last_active_time get_current_time_ms(); // 为这个连接创建一个每3秒检查一次的定时任务 uint64_t timer_id timer_add(mgr, 3000, check_connection_heartbeat, conn, 1); // 需要将timer_id与conn关联存储以便连接关闭时取消定时器 // ... }这个例子展示了如何将定时器与业务数据结构绑定。每个连接对象connection_t都有一个关联的周期性定时器定时检查其活跃度。当连接关闭时务必通过timer_cancel取消对应的定时器并释放conn内存这是防止内存泄漏和野指针的关键。Demo 3: 高性能场景下的批量定时任务测试这个demo用于压测和验证定时器在高负载下的表现。#define MAX_TEST_TIMERS 10000 void dummy_task(void *arg) { // 一个空任务仅用于测试调度性能 } int main() { timer_manager_t *mgr timer_init(10, 1000, 4); // 高精度10ms一 tick uint64_t timer_ids[MAX_TEST_TIMERS]; uint64_t start get_current_time_ms(); // 批量添加1万个在1秒后触发的定时器 for (int i 0; i MAX_TEST_TIMERS; i) { timer_ids[i] timer_add(mgr, 1000, dummy_task, NULL, 0); } uint64_t end get_current_time_ms(); printf(Added %d timers in %lld ms\n, MAX_TEST_TIMERS, end - start); // 等待所有定时器触发略长于1秒 sleep(2); // 批量取消虽然大部分已触发 start get_current_time_ms(); for (int i 0; i MAX_TEST_TIMERS; i) { timer_cancel(mgr, timer_ids[i]); } end get_current_time_ms(); printf(Cancelled %d timers in %lld ms\n, MAX_TEST_TIMERS, end - start); timer_cleanup(mgr); return 0; }通过这个测试你可以直观地感受到时间轮算法在管理大量定时器时的效率优势。添加和取消操作的平均时间复杂度接近O(1)不会因为定时器数量增多而明显变慢。5. 编译、集成与实战注意事项5.1 多平台编译指南源码包中会包含一个简单的Makefile用于Linux/macOS和一个timer.vcxproj用于Windows Visual Studio方便你快速编译。在Linux/macOS上编译# 进入源码目录 cd src # 编译静态库 make lib # 编译demo程序 make demo # 运行demo ./demo/demo_basic在Windows上使用Visual Studio打开timer.sln解决方案文件。选择Release配置和合适的平台x64或Win32。生成解决方案。这会编译出timer_static.lib静态库。将timer.h和库文件链接到你的项目中。对于更复杂的项目我建议使用CMake来管理这样可以真正做到一份配置多平台生成。源码包中也提供了一个基础的CMakeLists.txt示例。5.2 如何集成到你的项目中集成步骤非常简单遵循“包含头文件、链接库、调用API”的三步法拷贝文件将timer.h和timer.c或编译好的库文件放入你项目的源码树或库目录。包含头文件在你的业务代码中#include timer.h。链接如果直接使用源文件timer.c确保它被加入你的编译列表。如果使用预编译库在链接器设置中添加timer_static.libWindows或-ltimerLinux。初始化与使用在你的程序初始化阶段如main函数开头调用timer_init在退出前调用timer_cleanup。中间任意地方使用timer_add和timer_cancel。一个常见的集成模式是将其作为全局管理器或某个核心类的成员。例如在一个游戏服务器中你可能会有一个GameServer类其内部持有一个timer_manager_t*指针在构造函数中初始化在析构函数中清理。5.3 性能调优与参数选择定时器的性能主要受三个参数影响需要根据你的业务场景仔细选择tick_ms时间粒度这是最重要的参数。它决定了定时器的最小精度和调度线程的唤醒频率。设置得越小如1ms定时精度越高但调度线程空转消耗的CPU也越多。设置得越大如100msCPU占用低但所有定时器的触发时间都会有最多tick_ms的误差。我的经验是对于后台服务50ms-100ms的粒度是甜点区在精度和消耗之间取得了很好的平衡。对于UI动画或游戏逻辑帧可能需要10ms甚至更小。slot_num时间轮槽数它和tick_ms共同决定了能设置的最大定时间隔max_delay tick_ms * slot_num。例如tick_ms100,slot_num600则最大能设置60秒后的定时。如果你需要更长的定时比如半小时后有几种方案一是增大slot_num但这会增加内存开销二是实现“多级时间轮”类似秒针、分针、时针这是高性能定时器库如Netty的HashedWheelTimer的常见优化我的基础版本未实现但你可以基于此框架扩展。worker_thread_num工作线程数这取决于你的定时任务本身的性质。如果任务都是轻量级的如设置一个标志位1-2个线程就够了。如果任务可能阻塞或比较耗时如读写文件、进行网络请求那么需要配置与任务类型匹配的线程数避免任务队列堆积。你可以通过监控任务队列的长度来动态调整这个参数。避坑指南千万不要在定时器回调函数里进行长时间的阻塞操作这是新手最容易犯的错误。比如在回调里调用sleep(10)或者发起一个可能超时的网络连接而不设置超时。这会阻塞工作线程导致其他已到期的定时任务得不到及时执行整个定时系统的准确性就崩溃了。如果任务确实耗时请务必将其放入另一个专门的“慢任务队列”由其他线程池处理或者使用异步非阻塞的方式。6. 常见问题排查与调试技巧即使设计再完善在实际使用中还是会遇到各种问题。这里我总结几个最常被问到的和调试时最实用的技巧。6.1 定时不准误差越来越大可能原因及排查步骤调度线程被阻塞这是最常见的原因。首先检查你的回调函数callback里有没有可能阻塞的调用如文件IO、同步网络请求、锁竞争。可以用printf或日志在回调函数开始和结束时打时间戳计算执行耗时。如果耗时经常大于tick_ms那必然会导致后续定时任务延迟。系统负载过高调度线程的sleep或usleep并不保证精确休眠指定时间它只是“至少休眠这么久”。当系统负载极高时线程可能无法被及时唤醒。可以用get_current_time_ms()在调度循环里记录每次实际经过的时间如果远大于tick_ms说明系统调度延迟严重。时间轮参数设置不合理tick_ms设置得太小比如1ms而定时任务数量很多导致调度线程本身处理任务链表、加锁解锁的开销就占用了大量时间挤占了睡眠时间。尝试适当调大tick_ms。解决方案确保回调函数短小精悍快速返回。对于耗时操作改用“触发-队列”模式回调函数只负责向另一个队列投递任务。在Linux下可以考虑使用timerfd系列API配合IO多路复用如epoll来实现定时这通常比睡眠循环更精确且能更好地融入事件驱动架构。我的源码也提供了可选的timerfd实现供参考。6.2 内存泄漏问题定时器模块本身管理着任务结构体timer_task_t的内存。内存泄漏通常发生在用户层面。泄漏点1user_data指向的内存未被释放。当你调用timer_add时如果传递的arg参数是malloc分配的内存你需要在某个地方释放它。有两个时机在定时器回调函数里使用完user_data后释放。在调用timer_cancel取消一个未触发的定时器后因为回调不会被执行了你需要手动释放为其准备的user_data。泄漏点2周期性定时器忘记取消。如果一个定时器被设置为周期性is_periodic1它会不断被重新添加。如果你在业务上不再需要它比如对应的用户已下线却没有调用timer_cancel那么这个定时器会一直存在其关联的user_data也不会被释放。调试建议在调试阶段可以在timer_add和timer_cancel内部增加日志打印timer_id和对应的回调函数地址。在程序退出前让定时器管理器打印出所有尚未触发的定时器列表这能帮你快速定位“幽灵定时器”。6.3 多线程环境下的线程安全问题我的实现中时间轮任务链表的访问添加、删除、遍历都用互斥锁保护了这是线程安全的。但回调函数的执行环境——工作线程——是并发的这带来了新的问题。问题场景你有一个定时任务每隔一秒更新一个全局计数器int global_counter。同时主线程或其他线程也会读写这个计数器。如果没有同步措施就会发生数据竞争。// 错误示例定时器回调函数 void update_counter(void *arg) { global_counter; // 多线程并发访问危险 }解决方案如果共享数据很简单可以使用原子操作。例如在C11或C11中使用atomic_fetch_add。对于复杂的数据结构必须在访问时加锁。但要注意不要在回调函数内部等待一个可能被其他线程长期持有的锁这会导致工作线程被阻塞。尽量使用尝试锁pthread_mutex_trylock或设计无锁数据结构。一个更安全的模式是定时器回调只负责发出“事件”或“信号”具体的状态修改由持有该状态的主线程来执行。例如回调函数只是向一个无锁队列里放入一个“更新计数器”的请求主线程的事件循环从队列中取出请求并安全地修改global_counter。6.4 如何实现定时器的持久化与恢复这是一个高级话题。假设你的服务需要重启但希望重启后那些尚未执行的定时任务比如“一小时后给用户发提醒”还能继续生效。思路序列化你需要提供一个函数能够将定时器管理器中的所有待执行任务包括其到期时间、回调函数标识、参数等序列化到磁盘或数据库。注意回调函数指针是无法序列化的你需要用唯一的函数ID或名字来代替。持久化存储将序列化后的数据和当前时间戳一起保存。恢复服务启动时读取持久化数据计算每个任务剩余的延迟时间原到期时间 - 保存时的时间戳 当前时间戳然后重新调用timer_add添加这些任务。实现难点回调函数的恢复需要建立一个“函数ID到函数指针”的映射表。user_data的序列化如果user_data指向复杂的结构体你需要为其实现序列化/反序列化函数。 这个功能通常需要根据业务定制在我的基础源码中并未实现但它指出了定时器组件可以扩展的一个强大方向。最后分享一个我调试时常用的小技巧给定时器模块注入一个“慢速模式”的调试开关。在初始化时如果传入一个特殊的参数可以让调度线程的每个tick都打印出当前时间轮的状态有哪些任务何时到期并且将tick_ms临时放大10倍。这样你可以像看慢动作一样观察定时器的运行所有并发问题都更容易暴露出来。这个技巧帮我定位过好几个棘手的竞态条件问题。