std::priority_queue不能直接用于多线程任务调度，因其非线程安全且缺乏阻塞等待语义，粗粒度加锁导致严重串行化；应改用std::set+condition_variable实现细粒度并发调度。
为什么 std::priority_queue 不能直接用于多线程任务调度
因为 std::priority_queue 本身不是线程安全的，所有操作（push()、top()、pop()）都需外部加锁；更关键的是它不支持「等待非空时弹出」——也就是没有类似 wait_and_pop() 的阻塞语义，这会让消费者线程忙等或反复轮询，浪费 CPU。
常见错误是用 std::mutex 包裹单个 std::priority_queue，结果锁粒度太粗：每次 push() 或 pop() 都要独占整个队列，严重串行化任务入队/出队，吞吐骤降。
- 正确做法是分离「优先级比较」和「并发控制」：用线程安全的容器承载任务，自己维护堆语义或借助
std::set+ 自定义比较器 - 优先级字段必须是任务对象的一部分（如
task.priority），不能靠外部索引映射，否则并发修改时一致性难保证 - 避免在比较函数里调用可能阻塞或抛异常的逻辑（比如访问 shared_ptr 的 get() 后再解引用），否则
std::set插入可能崩溃
用 std::set + std::condition_variable 实现低竞争调度器
std::set 天然有序且支持 O(log n) 插入/删除，配合自定义比较器可按优先级排序；搭配 std::condition_variable 实现真正的阻塞等待，比手动 while-loop+sleep 高效得多。
关键点在于：比较器必须满足严格弱序，且不能依赖易变状态。推荐把优先级设计为整数（越小越高），并用 std::tuple 处理同优先级下的插入顺序（避免“饥饿”）：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
struct Task {
int priority;
uint64_t insert_seq; // 插入时单调递增
std::function<void()> fn;
};
struct TaskCompare {
bool operator()(const std::shared_ptr<Task>& a, const std::shared_ptr<Task>& b) const {
return std::tie(a->priority, a->insert_seq) < std::tie(b->priority, b->insert_seq);
}
};
- 用
std::shared_ptr<Task>存储，避免移动语义引发的比较器访问 dangling 对象 - 每次
push()时用原子计数器生成insert_seq，确保同优先级任务 FIFO -
std::condition_variable::wait()必须配合while (queue.empty())使用，防止虚假唤醒
如何避免高优先级任务饿死低优先级任务
纯优先级队列容易导致低优先级任务永远得不到执行（starvation），尤其当系统持续涌入高优任务时。这不是理论问题，而是真实负载下常见故障。
解决思路不是放弃优先级，而是引入「衰减机制」或「公平窗口」：
- 给每个任务附加
enqueued_time，比较器中加入「最大等待时间补偿」：当某任务等待超阈值（如 100ms），临时提升其有效优先级 - 改用分层队列：高优队列最多连续执行 3 个任务，就强制切到中优队列取一个，再切低优——用计数器 + 模运算实现，无额外锁开销
- 禁止任务在执行中动态修改自身优先级（会导致
std::set迭代器失效），如需调整，应取消原任务、新建更高优任务重新入队
性能敏感场景下该不该用 lock-free priority queue
目前主流标准库和 Boost 都不提供生产可用的 lock-free 优先级队列。自行实现极易出错：CAS 操作需同时更新堆结构多个节点，ABA 问题在优先级场景下更隐蔽（比如两个不同任务有相同 priority 值，被误判为同一节点）。
实测表明，在中等并发（≤ 8 生产者 / ≤ 4 消费者）下，带细粒度锁的 std::set 方案吞吐反而高于粗糙的 lock-free 尝试——后者因重试频繁、缓存行冲突多，实际延迟更高。
- 若真需极致性能，建议用
moodycamel::ConcurrentQueue搭配多个固定优先级的无锁队列（如 3 级：high/normal/low），由调度线程按权重轮询 - 注意：Linux 的
SCHED_FIFO或 Windows 的线程优先级 API 无法替代任务级优先级，它们只影响线程调度，不控制任务执行顺序 - 调试时重点观察
std::set::size()波动和消费者线程 wait 时间分布，突增的 size 通常意味着生产者过载或消费者卡在某个任务里
