应使用std::shared_ptr替代裸指针存储任务，配合自定义比较器实现大根堆；需在调度循环中try/catch捕获任务异常；多线程下仅对队列操作加锁；同优先级时引入sequence_id保证fifo；动态改优先级需重新入队。
用 std::priority_queue 管理任务优先级，但别直接存裸指针
优先级调度的核心是每次取最高优先级任务执行，std::priority_queue 天然适配。但直接塞 Task* 容易悬空或内存泄漏——比如任务对象提前析构，队列里还留着野指针。
推荐用 std::shared_ptr<task></task> 存储，配合自定义比较器：
struct Task {
int priority;
std::function<void> action;
Task(int p, std::function<void> a) : priority(p), action(std::move(a)) {}
};
struct ComparePriority {
bool operator()(const std::shared_ptr<task>& a, const std::shared_ptr<task>& b) {
return a->priority priority; // 大根堆：priority 越大越先执行
}
};
std::priority_queue<:shared_ptr>, std::vector<:shared_ptr>>, ComparePriority> taskQueue;</:shared_ptr></:shared_ptr></task></task></void></void>
注意：std::priority_queue 默认是最大堆？不是——它默认用 std::less，对内置类型表现为“大值在前”，但自定义比较器必须明确语义：返回 true 表示 a 应该排在 b 后面（即 a 优先级更低）。
任务执行时要处理异常，否则整个调度器可能卡死
taskQueue.top()->action() 一旦抛异常且未捕获，后续所有任务都执行不了。这不是理论风险，而是真实场景中回调函数调用外部 API 或解析数据时高频发生的问题。
- 务必在调度循环中用
try/catch包裹单个任务执行 - 记录错误日志，但不要让异常穿透出调度逻辑
- 考虑是否需要重试机制（比如加一个
retry_count字段）
简单防护写法：
while (!taskQueue.empty()) {
auto task = taskQueue.top();
taskQueue.pop();
try {
task->action();
} catch (const std::exception& e) {
// 记录日志，比如：std::cerr
<h3>多线程环境下必须加锁，但别锁整个调度循环</h3>
<p>如果生产者（提交任务）和消费者（执行任务）在不同线程，<code>taskQueue</code> 是非线程安全的。常见错误是把 <code>push()</code> 和 <code>pop()</code> 都包进同一个 <code>std::mutex</code>，导致高并发时任务提交被阻塞在执行逻辑上。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2823" title="C++14"><img
src="https://img.php.cn/upload/manual/001/431/639/6ac8b33c327c4749.png" alt="C++14" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="overflowclass">C++14</a>
<p class="overflowclass">C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<p>更合理的做法：</p>
- 用独立的
std::mutex保护队列本身（push/top/pop） - 执行任务前就释放锁，避免阻塞其他线程提交新任务
- 若需保证“任务提交后尽快执行”，可搭配
std::condition_variable唤醒空闲工作线程
关键点：锁的粒度只覆盖队列操作，不覆盖 task->action() 的实际耗时执行。
优先级相同时，std::priority_queue 不保证插入顺序
当两个任务 priority 相同，std::priority_queue 可能任意打乱它们的相对顺序——底层是堆结构，不维护 FIFO。如果你依赖“先提交先执行”的公平性（比如同优先级任务），必须显式引入序号。
解决方法很简单：给 Task 加一个 uint64_t sequence_id，在比较器中作为第二排序键：
struct ComparePriority {
bool operator()(const std::shared_ptr<task>& a, const std::shared_ptr<task>& b) {
if (a->priority != b->priority) {
return a->priority priority;
}
return a->sequence_id > b->sequence_id; // 小序号优先
}
};</task></task>
别忘了在构造 Task 时用原子递增的全局计数器生成 sequence_id，否则多线程下会重复。
真正麻烦的是优先级动态变化——std::priority_queue 不支持修改已入队元素的优先级。要么重新 push 新任务并标记旧任务失效，要么换用 std::set + 迭代器，但后者要自己管理迭代器失效问题。大多数轻量级调度器选择前者，用 std::shared_ptr 的引用计数自然淘汰旧任务。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
