定时器任务的状态机设计，本质上是将“启动—运行—到期—清理”这一完整生命周期显式建模，而非依赖时间戳或布尔标志进行隐式判断。状态定义模糊不清、状态跳转缺乏约束、清理操作滞后——这三者叠加，几乎必然滋生竞态条件，进而影响系统稳定性。

状态定义必须覆盖所有可观测行为

仅靠两个状态远远不够，至少需要五个。

• idle：定时器已创建但尚未启动，回调函数未注册，资源也未分配
• armed：已调用start接口，但尚未触发——内核定时器虽已挂入队列，计时未到
• firing：回调函数正在执行中。这是整个流程中最关键的临界区域
• expired：执行完毕且不重复，等待销毁
• cancelling：已收到cancel请求，但回调可能仍处于firing状态

例如，RTX5中禁止使用osTimerStart(ticks=0)，根本原因在于armed → firing这一瞬时跳转会绕过状态校验，使内核在锁外误以为定时器已就绪。此类问题在工程实践中非常隐蔽，却足以导致整个调度链路崩溃。

状态迁移必须原子且可验证

每次状态变更，都必须通过CAS或带锁的写入完成，且需返回旧状态用于逻辑分支判断。

以下写法应坚决避免：

if (state == armed) state = firing; // 非原子操作，存在竞态窗口

正确的做法是：

• 使用std::atomic::compare_exchange_strong（C++）或AtomicReference.compareAndSet（Java），确保单次迁移成功后，再继续后续操作。
• 所有外部操作（start/cancel/stop）必须先读取当前状态，再按预定义规则判断是否允许迁移。例如，从cancelling状态不允许再进入firing状态。
• 回调函数入口处需再次校验状态是否仍为firing，防止被重复调度。

资源生命周期与状态严格绑定

状态并非装饰品，而是资源管理的指令：

• 仅在armed状态下，才允许调用内核timer API注册超时事件。
• 仅在firing状态下，才能访问用户回调指针和参数内存——且需确保其生命周期至少覆盖firing期间。
• 仅在expired或cancelling状态下，才能释放定时器结构体的内存。
• 任何状态迁移失败的情形（如cancel时发现已是expired），都应明确返回错误码，而非静默忽略。

回顾Tokio中watch::Sender::send与接收端的竞争问题，根源在于发送动作未检查channel是否已被drop。映射到定时器场景：如果cancel不确认当前是否处于可取消状态，就直接清空队列指针，内核红黑树的结构一致性将被破坏。

避免TOCTOU类型的时间窗口

典型陷阱是：先查询is_running()返回true，再调用cancel()，但中间时刻定时器已自动expire并释放了内存，结果直接踩空。

正确的处理方式：

• 将“检查+操作”合并为一个原子调用，例如try_cancel() → Result。
• 对共享状态（如timer结构体指针）使用引用计数或弱引用，确保cancel时对象仍然有效。
• 在多线程环境下，所有状态读取需加acquire语义，所有写入需加release语义。

该方案比单纯加mutex更轻量，也更能满足定时器场景对高频、低延迟的苛刻要求。