为什么标准 std::Thread 池没法直接支持工作窃取
因为工作窃取本质依赖每个线程维护自己的双端队列（std::deque 或自定义 concurrent_deque），并允许其他线程从队尾“偷”任务；而 std::thread 本身不管理任务队列，更不暴露线程本地存储接口。你得自己封装线程+本地队列+跨线程偷取逻辑。
常见错误是只用一个全局 std::queue + std::mutex —— 这叫「集中式调度」，锁争用严重，根本不是工作窃取，也谈不上负载均衡。
- 必须为每个工作线程分配独立的
task_queue（推荐用std::deque，支持 O(1) 队首取、O(1) 队尾推/弹） - 所有线程需能访问彼此的队列指针（通常存进
std::vector<:unique_ptr>></:unique_ptr>） - 偷取动作必须是「尝试性」的：先锁对方队列尾部一小段（比如用
try_lock），失败就立刻放弃，避免反向阻塞
std::deque 为什么比 std::queue 更适合做本地任务队列
std::queue 是适配器，默认底层是 std::deque，但它只暴露 front()/pop() 和 back()/push() 中的一组——你无法同时高效地从头消费、从尾插入（这是工作线程主循环必需的），更无法从尾弹出（偷取需要 pop_back()）。
直接用 std::deque 才能控制两端操作：
立即学习“C++免费学习笔记（深入）”；
- 工作线程主循环：用
pop_front()取自己队列的任务（LIFO 局部性更好） - 其他线程偷取时：用
pop_back()尝试拿走最“新”的任务（减少缓存失效） - 提交新任务到某线程：用
push_back()放入其本地队列
注意：std::deque 的迭代器在扩容时可能失效，但只要不遍历、只用 push/pop 系列操作，线程安全由你加的锁保证，没问题。
偷取失败时该立刻休眠还是继续轮询
立刻休眠（如 std::this_thread::yield() 或短时 std::this_thread::sleep_for(1ns)）是更稳妥的选择。连续空转轮询不仅浪费 CPU，还可能因缓存乒乓（cache bouncing）拖慢所有线程。
典型错误是写成 while(!try_steal()) {} —— 在四核机器上，3 个空闲线程死等 1 个忙线程的队尾，结果谁都跑不快。
- 建议策略：最多尝试 2–3 次偷取（遍历其他线程队列顺序可随机打乱，避免固定竞争热点）
- 失败后调用
std::this_thread::yield()，让出当前时间片 - 若仍无任务，再检查全局等待队列（如有）、或进入条件变量等待（比如用
std::condition_variable配合notify_one()在 push 时唤醒）
如何避免偷取引发虚假共享（false sharing）
多个线程频繁读写相邻的 deque 头尾指针（如 begin_ / end_），哪怕各自操作不同字段，也可能落在同一 cache line，导致反复同步——性能暴跌。
实操上必须手动对齐隔离：
- 把每个 Worker 的
std::deque和控制字段（如size、is_idle）分别放在独立的 cache line（64 字节）里 - 用
alignas(64)修饰结构体或关键成员，例如：struct alignas(64) Worker { std::deque<Task> local_queue; std::atomic<bool> idle{true}; }; - 不要把多个 Worker 实例紧凑数组存放——它们的
local_queue内部指针可能又挤在一起；改用std::vector<:unique_ptr>></:unique_ptr>，让分配器自然分散地址
这个细节在高并发下影响极大，但调试器里完全看不出来，只能靠 perf 工具观察 cache-misses 指标确认。