标准库的 runtime.gomaxprocs 不够用，因其 work-stealing 仅限 m-p-g 层面，无法感知用户态任务；当 p 的本地队列塞满长耗时任务时，新 goroutine 只能排队，无法被偷取，导致负载不均与 cpu 利用率低下。
为什么标准库的 runtime.GOMAXPROCS 不够用
Go 的调度器确实自带 work-stealing，但那是 runtime 层面的 M-P-G 协作，对用户态任务（比如你手写的 goroutine 池、分片计算任务、自定义 worker 队列）完全不感知。你看到的“goroutine 被自动均衡”只是假象——一旦所有 P 的本地运行队列都塞满长耗时任务，新启动的 goroutine 就只能排队等，根本不会被“偷”。
常见错误现象：pprof 显示某些 P 的 goroutines 数量长期远高于其他 P；go tool trace 里能看到大量 goroutine 在 runnable 状态卡住，但 CPU 利用率却上不去。
- 使用场景：批处理分片（如 100 个子任务分配给 8 个 worker）、递归并行（如并行 quicksort 分治后子数组处理）、IO+CPU 混合型 pipeline 中的计算阶段
- 关键区别：runtime 的偷是 M 在无 G 可运行时跨 P 偷，而你要做的是 worker goroutine 主动从其他 worker 的任务队列里“非阻塞地拿一个”
- 性能影响：本地队列用
sync.Pool复用[]*Task切片能减少 GC；但若偷任务时用锁保护共享队列，反而比单队列还慢
sync.Pool + atomic 实现无锁本地队列
每个 worker 维护自己的双端队列（deque），push 入队尾，pop 从队首取；被偷时则从队尾“尝试性”取一个——这是避免锁的关键。Go 标准库的 runtime.runq 就是这么干的。
典型错误：用 chan 当本地队列，结果所有 worker 都往同一个 chan send，变成串行瓶颈；或者用 sync.Mutex 包裹 slice 的 append 和 pop，偷任务时还要加锁，彻底失去并发意义。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
atomic.LoadUint64/atomic.StoreUint64管理头尾指针，不能靠len()或cap() -
sync.Pool用来复用 deque 结构体本身，不是复用 task；task 对象建议由调用方管理生命周期 - 偷任务函数命名建议带
trySteal，返回 bool 表示是否成功，避免误以为“一定能偷到”
worker 启动时如何触发偷逻辑
偷不是定时轮询，也不是每执行完一个 task 就去偷一次。真实高效的做法是：当本地队列为空，且全局“有活可偷”的信号为真时，才尝试偷；偷失败就 park，而不是忙等。
容易踩的坑：for range 循环里每次 task 执行完都调用 trySteal()，导致大量原子操作和伪共享；或者用 time.Sleep(1 * time.Microsecond) 做退避，浪费调度器时间片。
- 用
runtime.Gosched()替代 sleep：让出当前 M，允许其他 goroutine 运行，同时不增加系统线程切换开销 - 设置偷尝试上限（比如最多试 3 次），之后直接
select {}等待新任务被投递到本地队列 - “有活可偷”信号可用
atomic.LoadInt32(&stealableWorkers)，由任务入队/出队时增减，避免每次偷都遍历全部 worker
如何验证偷行为真的发生了
别只看吞吐量提升——那可能是别的优化带来的。要确认偷在起作用，得观测 worker 间任务分布是否趋近均衡，以及偷调用的成功率。
最常忽略的一点：日志或 metrics 打点本身会成为瓶颈。比如每个 trySteal 都 log.Printf，结果 IO 拖垮整个调度。
- 用
expvar.NewInt("worker_0_steal_success")这类轻量计数器，运行时通过/debug/vars查看 - 在 trace 中搜索
steal关键字：给偷操作加上trace.Log，但仅限 debug build，上线关闭 - 对比实验：关掉偷逻辑（所有 worker 只读本地队列），跑同样 workload，观察 P99 延迟是否明显拉长、是否存在个别 worker 长期空闲
work stealing 的复杂点不在实现 deque，而在于“何时偷、偷多少、偷不到怎么办”这三件事的节奏感。很多人写完 deque 就以为完成了，结果在高负载下反而因为频繁偷失败导致 goroutine 雪崩式 park/unpark。
