真正Work-Stealing要求每个线程独占本地无锁双端队列，push_back/pop_back本线程执行，其他线程仅能原子尝试pop_front；std::deque+全局锁仍是中心化队列，无法避免锁竞争与缓存失效。
为什么 std::deque + 全局锁做不了真正的 Work-Stealing
直接用 std::deque 配一个全局 std::mutex，所有线程抢同一把锁取任务，本质上还是中心化队列——这不是 Work-Stealing，只是带队列的线程池。它会在高并发下迅速暴露锁竞争、缓存行失效和虚假共享问题。
真正 Work-Stealing 的前提是：每个线程有自己独占的、**本地无锁**操作的双端队列，且“偷”和“执行”方向必须分离：
- 本线程
push_back()/pop_back()（LIFO，局部性好） - 其他线程只能从该队列
front()尝试拿（FIFO，避免与 pop_back 冲突） -
pop_front()必须加细粒度锁或封装为原子尝试操作，不能裸调 - 若用
std::stack代替std::deque，则无法安全支持偷取——因为没front()
如何设计每个线程的本地队列结构
工业级实现（如 TBB、Folly）不用 std::deque，而是用数组 + 两个原子索引模拟双端队列，避免内存不连续和迭代器失效。但对多数项目，折中方案更实用：
- 每个 worker 持有一个
std::deque<:function>>+ 一个std::mutex（仅用于偷取路径） - 额外维护一个
std::atomic_size_t m_size，供空检查快速判断，避免每次偷前都锁住 deque - 本地 push/pop 完全不加锁：
local_tasks.push_back(task)→m_size.fetch_add(1, std::memory_order_relaxed) - 偷取时先读
m_size.load(std::memory_order_acquire)，若 >0 再尝试加锁并pop_front() - 务必在
pop_front()后同步递减m_size，否则其他线程可能反复偷到空队列
窃取逻辑里最容易忽略的三个细节
很多实现卡在“能跑通”，但一压测就出负载不均或 crash，往往栽在这几个点：
- 偷取失败后不退避：连续
try_lock()失败应调用std::this_thread::yield()或sleep_for(1ns)，否则空转耗尽 CPU - 随机目标选择没排除自身：
rand() % n_threads可能选到自己，导致死锁或无效重试 - 没做 memory_order 约束：读对方
m_size必须用memory_order_acquire，写本地m_size用memory_order_release，否则看到过期值或乱序更新
主线程提交任务该进哪个队列
提交入口 submit() 不该一股脑塞进全局队列，也不该固定扔给某一个 worker。正确做法是：
- 若当前线程是 worker 线程（可通过 TLS 或线程 ID 判断），优先 push 到自己的本地队列尾部
- 若当前是主线程或其他非 worker 线程，则轮询选择负载最轻的 worker：比较各
m_size.load()，选最小的那个 push - 禁用“始终提交到固定索引”策略——这会导致任务生成集中，引发饥饿
- 若所有本地队列都满（比如设置了上限），再 fallback 到一个全局 MPSC 队列，由空闲 worker 主动消费
伪共享、内存序错配、偷取方向反了——这些不是边缘 case，而是上线后 CPU 利用率卡在 50% 的真实原因。Work-Stealing 的“高性能”不来自算法本身，而来自对每个原子操作的意图和约束的精确控制。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
