必须显式引入负载感知机制，因标准线程池无法自动均摊：共享队列导致唤醒随机、锁竞争、长任务阻塞短任务、无反压；应改用本地队列+最小负载选择，以原子计数器实现无锁调度。
不能靠线程池自身“自动均摊”，必须显式引入负载感知机制。标准 std::thread 或基础线程池（如仅用 std::queue + std::mutex）在高并发下天然存在任务堆积、唤醒不均、缓存行竞争等问题，负载会迅速倾斜——尤其当任务执行时间差异大或节点硬件不一致时。
为什么 std::queue + condition_variable 无法保证负载平衡
这是最常被误用的“伪均衡”方案：所有工作线程共用一个任务队列，靠 cv.notify_one() 唤醒任意空闲线程。问题在于：
- 唤醒是随机的，不考虑线程当前真实负载（比如某线程刚结束一个耗时 200ms 的任务，另一线程刚启动）
- 多个线程争抢同一把
queue_mutex，在千万级 QPS 下锁竞争直接成为瓶颈 - 任务入队顺序 ≠ 执行顺序，长任务阻塞短任务，导致响应时间毛刺（tail latency）飙升
- 没有反压机制：生产者持续投递，队列膨胀 → 内存占用激增 + 调度延迟不可控
用 Backend 状态 + 最小负载选择替代“盲分发”
参考 AI 推理服务中 LoadBalancer::select() 的思路，把“谁来干活”从队列调度层上提到业务逻辑层。关键不是让线程抢任务，而是让任务主动选线程：
- 每个工作线程维护本地
currentLoad计数器（原子变量，避免锁），记录正在处理的任务数 - 提交任务前，调用
select_least_loaded_worker()扫描所有 worker 的currentLoad，选最小值对应线程 - 通过线程专属队列（如 per-worker
moodycamel::ConcurrentQueue）投递，绕过全局锁 - 执行完任务后，worker 自增/自减本地计数器，无需跨线程同步
示例片段：
立即学习“C++免费学习笔记（深入）”；
struct Worker {
std::atomic_int currentLoad{0};
moodycamel::ConcurrentQueue<Task> queue;
};
<p>Worker<em> select_least_loaded_worker() {
Worker</em> best = nullptr;
int min = INT_MAX;
for (auto& w : workers) {
int load = w.currentLoad.load(std::memory_order_relaxed);
if (load < min) {
min = load;
best = &w;
}
}
return best;
}</p><p>// 提交时
auto* w = select_least_loaded_worker();
w->queue.enqueue(task);
w->currentLoad.fetch_add(1, std::memory_order_relaxed);</p>避免 RCU 或读写锁的过度设计
有人试图用 std::shared_mutex 保护整个 worker 列表，或引入 RCU 更新 backend 列表——这在动态扩缩容场景下反而引入复杂性与延迟。实际工程中：
- worker 数量通常固定（等于
std::thread::hardware_concurrency()），列表本身极少变更 - 只需对
currentLoad使用std::atomic_int，读写都无锁，吞吐量可达千万 ops/sec - 若需增删 worker，用
std::vector<std::unique_ptr<Worker>>+std::shared_mutex保护 vector 本身即可，不影响运行时负载判断 - RCU 在 C++ 中实现成本高、调试困难，除非你已在用 Linux kernel 风格基础设施，否则不值得
真正难的不是选哪个线程，而是定义“负载”本身：仅用计数器适合 CPU-bound 任务；对 GPU 推理或 IO 等待型任务，必须融合 gpuUtil、pendingIOCount 等指标加权计算——这部分逻辑一旦写死，就很难热更新，得预留配置接口。
