p空闲时从其他p队列尾部偷g是为了避免与本地出队竞争头部、保持无锁设计；尾部偷取仅需原子调整runqtail，冲突低，且每次只偷一半g并随机轮询其他p。
为什么P空闲时要从其他P队列尾部偷G，而不是头部
因为本地队列是环形缓冲区（runq），用runqhead和runqtail索引管理，G入队走尾部、出队走头部——这是典型的FIFO。若窃取也从头部拿，会和当前P的出队操作竞争同一位置，必须加锁或原子操作，破坏无锁设计初衷。
尾部偷取本质是“读取并移动runqtail”，只影响窃取方P的局部状态，被偷P只需保证自己不同时修改runqtail（实际通过原子减法+内存屏障实现），冲突概率极低。Go运行时源码中runqsteal函数明确使用atomic.Xadd调整尾指针，并只取一半G（避免把对方队列掏空）。
- 偷取数量固定为
len/2向上取整，不是全拿，保留被偷P后续调度余量 - 偷取失败（如对方队列已空或正在被修改）直接跳过，不重试，避免自旋开销
- 偷取顺序是随机轮询其他P，不是按编号顺序，防止多个空闲P集中攻击同一个忙P
stealWork()调用时机与失败后的行为
stealWork()不是独立函数，而是findRunnable()调度主循环中第4阶段的封装逻辑。它只在以下条件全部满足时才触发：
- 当前P的
runq为空（runqget返回nil） - 全局队列
globrunqget也未拿到G - 网络轮询器
netpoll无就绪G
此时进入4轮窃取尝试（硬编码for i := 0; i ），每轮遍历所有P（跳过自身），随机起始位置。一旦某次窃取成功，立即返回G；若4轮全失败，M将与P解绑，进入休眠等待唤醒。
注意：这不是“尽力而为”的负载均衡，而是“保底兜底”机制——只有本地+全局+网络三路都无G可取时才启动，避免无谓的跨P访问开销。
work stealing对GOMAXPROCS设置的实际影响
GOMAXPROCS设的是P的数量，直接影响工作窃取的拓扑规模。设得太小（如GOMAXPROCS=1）：只有一个P，stealWork()永远不执行（没其他P可偷），退化为单线程调度，所有G串行跑；设得太大（如远超CPU核心数）：P过多导致LRQ普遍偏短，窃取命中率下降，反而增加跨P缓存失效和伪共享概率。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
真实瓶颈常不在P数量，而在G的分布不均。例如一个P长期执行阻塞型系统调用（如syscall.Read），其runq持续为空，其他P反复向它发起窃取请求却总失败，白白消耗CPU周期。这种场景下，调整GOMAXPROCS无用，需检查G是否合理拆分IO密集型任务。
如何验证当前程序是否发生了work stealing
Go运行时不提供直接API暴露窃取次数，但可通过runtime.ReadMemStats间接观察：MemStats.NumGC变化本身无关，重点看MemStats.PauseNs中长尾延迟——频繁窃取会拉高调度延迟，表现为runtime.findRunnable耗时突增。
更可靠的方式是启用调度追踪：
go run -gcflags="-l" -ldflags="-s" -trace=trace.out main.go go tool trace trace.out
在Web界面中打开“Scheduler”视图，观察“Proc”栏下各P的“Runnable Gs”曲线：若某P长期为0，而其他P曲线剧烈抖动（骤降后回升），大概率是它在持续窃取。另外，“Steal”事件在底层trace event中对应runtime.traceEventSteal，但需编译时加-tags=trace才启用，生产环境慎用。
真正难调试的不是“有没有窃取”，而是“为什么总在窃取”——那往往意味着你的G在某个P上堆积/阻塞，或者网络I/O未正确使用netpoll机制卸载到异步路径。
