撤回操作本身无优先级，真正生效的是调度器对任务状态的感知粒度和撤回请求的插入时机；需将撤回指令作为带优先级的可调度对象参与排序，并在任务执行中主动轮询取消状态。
任务撤回时优先级怎么不生效？
撤回操作本身没有优先级概念，真正起作用的是「调度器对任务状态的感知粒度」和「撤回请求的插入时机」。常见错误是把 cancel(task_id) 当成原子操作，实际它只是标记任务为 CANCELLED；如果任务已进入执行队列（比如在 worker 线程中正调用 run()），撤回就只能等它自己检查状态并退出——这时候优先级根本没机会介入。
正确做法是：撤回请求必须走同一条调度路径，参与优先级排序。例如用一个带优先级的 std::priority_queue 存储待处理的撤回指令，按原任务优先级逆序排列（高优任务的撤回应被更快响应）。
- 撤回指令封装为独立可调度对象，包含原任务 ID、撤回优先级（通常 = 原任务优先级）、时间戳
- 调度器主循环每次 tick 都先 pop 撤回指令，再 pop 执行任务，避免“高优任务刚入队就被低优撤回覆盖”
- 任务基类必须提供
should_stop()接口，且要求所有耗时操作（如循环、IO 等待）中定期轮询该接口
std::priority_queue 为什么不能直接存 std::shared_ptr？
因为默认比较器只比指针地址，不是任务优先级。你看到的“按优先级排序”其实是巧合——内存分配顺序偶然接近优先级顺序。
必须自定义比较器，并确保它读取的是任务内部的 priority() 值（而非创建时的快照）。否则一旦任务运行中动态调整了优先级（比如因依赖资源就绪而升级），std::priority_queue 就完全无法反映变化。
立即学习“C++免费学习笔记（深入）”；
- 用
std::vector<:shared_ptr>></:shared_ptr>+std::make_heap替代，便于后续std::push_heap/std::pop_heap手动维护 - 比较器里调用
a->priority() > b->priority()（注意是>，因为std::priority_queue是大顶堆） - 撤回操作不删除任务对象，只调
task->set_state(TaskState::CANCELLED)，防止野指针
多线程下撤回失败但没报错？
典型现象是调用了 cancel(id)，返回 true，但对应任务仍在运行。这不是 bug，是设计使然：C++ 没有抢占式取消机制，所有“撤回成功”都只是「调度器不再派发该任务」，不等于「正在执行的任务立刻停」。
真正影响行为的是三处同步点：任务入队时、worker 线程取任务时、任务执行体内的主动检查点。漏掉任意一处，撤回就不可见。
- worker 线程取任务后，必须立即检查
task->state() == CANCELLED，是则跳过执行 - 任务执行函数内，每个逻辑段后加
if (is_cancelled()) return;，尤其在sleep、wait、read前 - 避免在
std::mutex持有期间长时间阻塞——这会让撤回指令卡在队列里，直到锁释放
为什么撤回高优任务反而拖慢整个调度器？
因为高频撤回会引发「优先级重排风暴」：每次撤回都要遍历整个待执行队列，重新建堆，O(n log n) 开销。当任务优先级差异大、撤回频次高时，调度器 CPU 占用飙升，新任务入队延迟变大。
这不是算法问题，是数据结构误用。用红黑树（std::set）或跳表（需手写）替代堆，支持 O(log n) 删除+插入，但代价是失去“取最高优任务”的 O(1) 性能。
- 折中方案：分桶调度——按优先级范围切分多个
std::priority_queue，撤回只清对应桶，避免全局重排 - 撤回指令加时间衰减因子，相同优先级下，更早发出的撤回排在前面，防堆积
- 对实时性要求极高的场景，撤回操作应绕过主调度队列，直接写入 per-worker 的无锁环形缓冲区
复杂点从来不在“怎么撤回”，而在“撤回指令如何与任务生命周期对齐”。多数崩溃或逻辑错乱，都源于撤回时假设任务还处于某个固定状态——而它可能正在析构、正在等待锁、甚至已经执行完毕但还没来得及更新状态字段。
