std::chrono+std::thread无法支撑万级定时任务，因线程调度开销大、sleep精度低、栈与内核资源耗尽；应弃用单任务单线程模型，改用时间轮（哈希/分层）配合timerfd+epoll或condition_variable批量调度。
为什么 std::chrono + std::thread 无法撑住万级定时任务
直接用 std::this_thread::sleep_for 轮询或为每个定时任务起一个线程，在任务数超过几百后就会明显卡顿甚至崩溃。根本原因是：系统线程调度开销大，且 sleep 精度受 OS 调度周期影响（Linux 默认 1–10ms），std::chrono::steady_clock 再准也没法让线程准时唤醒；更关键的是，大量 std::thread 对象会快速耗尽栈内存和内核线程资源。
实操建议：
- 单任务单线程模型必须放弃，哪怕只跑 500 个 1s 定时器，线程创建/销毁成本也远高于调度本身
- 避免在循环中反复调用
sleep_for(1ms)做“软轮询”——这会导致 CPU 空转或唤醒抖动，epoll_wait或timerfd_create才是内核级等待的正确姿势（Linux） - 若必须跨平台，优先用
std::condition_variable::wait_until配合一个共享的最小到期时间，而不是每个任务都 wait
时间轮结构选型：哈希时间轮 vs 分层时间轮
哈希时间轮（Hashed Timing Wheel）适合短周期、高密度任务（如 10ms–5s 内到期），插入 O(1)，但删除需遍历桶；分层时间轮（Hierarchical Timing Wheel，如 Kafka 的 SystemTimer）支持长周期（小时/天级），空间换时间，但指针跳转和层级计算带来额外分支开销。
实操建议：
- 若业务场景是“连接心跳（30s）、请求超时（2s）、重试退避（100ms–5s）”，选单层哈希时间轮，槽位数设为 2048 或 4096，步长取 10ms，覆盖 20s–40s 时间窗口足够
- 不要盲目套用多层结构——每层增加一次模运算和指针解引用，当 95% 任务在 1s 内到期时，第二层几乎不被访问，纯属冗余
- 桶内任务链表必须用 intrusive list（即节点自带
next指针），避免每次触发时 new/delete；C++20 可用std::intrusive_ptr管理生命周期，但更轻量的做法是预分配 slab 内存池
如何安全地从任意线程添加/取消定时任务
典型错误是多个线程直接操作时间轮的槽数组，导致 segfault 或漏触发。核心矛盾在于：插入/删除需修改链表指针，而 tick 线程在遍历执行，二者必须同步，但锁粒度太大会串行化整个轮子。
实操建议：
- 采用“无锁写入 + 批量合并”策略：每个工作线程写入自己的
std::vector缓冲区，tick 线程每次 tick 前原子交换并清空该缓冲区，再批量插入到对应槽位 - 取消任务不能只标记“已取消”，必须从链表中物理移除——否则 tick 线程仍要遍历无效节点；推荐在
TaskEntry中加std::atomic_bool canceled{false}，插入时置 false，取消时置 true，tick 执行前检查，执行中跳过 - 禁止在回调函数里调用
cancel()或schedule()—— 这会引发重入，应改用 post 到调度器内部队列异步处理
Linux 下用 timerfd_settime 实现精准 tick 触发
靠 std::this_thread::sleep_for 驱动 tick，误差会随负载累积。用 timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK) 创建定时器 fd，配合 epoll_wait，可做到 sub-ms 级唤醒精度，且完全不占用 CPU。
实操建议：
- 初始化时调用
timerfd_settime(fd, 0, &spec, nullptr)，其中spec.it_value.tv_nsec = 10'000'000（10ms），it_interval设相同值，形成稳定 tick 流 - epoll event loop 中检测该 fd 可读时，务必
read(fd, &exp, sizeof(exp))清空计数器，否则下次 epoll_wait 会立即返回——这是最常被忽略的点 - 不要把 timerfd 和 socket fd 混在同一个 epoll 实例里做高并发 I/O——timerfd 触发频率固定，而网络 fd 波动大，混用会导致 epoll_wait 返回批次不稳定，建议分离
真正难的不是实现 tick 或插槽，而是任务生命周期与调度器线程模型的对齐：回调执行上下文、异常是否吞没、内存释放时机、跨线程取消的可见性——这些细节不处理好，性能再高也会在压测时崩出 use-after-free 或静默丢任务。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
