go工作窃取是刚性调度逻辑，仅在当前p的runq、runnext、全局队列和netpoll全空时，由findrunnable调用runqsteal触发；最多尝试4轮伪随机窃取，每次偷目标p队列长度一半（上限32个）且仅从尾部取，不加锁依赖原子操作与双端队列隔离。
Go 的工作窃取（Work Stealing）不是语言学习阶段的“负载均衡教学案例”，而是运行时调度器中真实、刚性、不可绕过的执行逻辑——它不依赖你是否理解，只要 Goroutine 数量超过 P 的本地队列容量，它就自动触发。
workqsteal 函数是窃取行为的实际执行者
所有“偷 G”的动作都由 runqsteal 完成，它被 findrunnable 显式调用，且仅在以下条件全部满足时才进入：当前 P 的 runq 为空、runnext 为 nil、全局队列 globrunqget 拿不到 G、netpoll 也无就绪 G。此时调度器才开始尝试窃取。
常见误判是以为“P 空闲几毫秒就会自动扫描其他 P”，实际它完全不扫描——只按固定轮次（最多 4 次）、随机偏移（fastrand() % gomaxprocs）选目标 P，失败即止。
-
runqsteal不加锁，靠原子操作更新目标 P 的runqtail和runqhead，但要求内存序严格（atomic.LoadAcq/atomic.StoreRel） - 每次只偷目标 P 队列长度的一半（向下取整），上限硬编码为 32 个，绝不会清空对方队列
- 偷的是尾部（
runq.popTail()），不是头部；头部留给本 P 自己 pop，避免与runqget竞争
stealRunNextG 参数决定是否抢 runnext
在 findrunnable 中首次调用 runqsteal 时，传入的 stealRunNextG 为 true，意味着它会先尝试用 atomic.Casuintptr 抢走目标 P 的 runnext 字段——这个 G 通常是刚唤醒或刚创建、有更高执行优先级的 Goroutine。
但注意：runnext 不是强保证。它可能已被其他 M 成功抢走，也可能在 CAS 过程中被本 P 的下一次调度覆盖。所以“抢 runnext”只是优化路径，失败就跳过，不影响后续偷队列。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 若目标 P 的
runnext已被占用，CAS 失败，runqsteal直接忽略，继续偷尾部队列 - 即使抢到
runnext，它也会被立即插入当前 P 的本地队列尾部（而非头部），后续仍按 FIFO 被runqget取出 - 这个设计让高优先级 G 更快被发现，但不破坏整体 FIFO 调度语义
为什么偷尾部而不是头部？本质是避免锁竞争
如果从头部偷，就和目标 P 自身的 runqget（从 head pop）发生同一缓存行争用，必须引入更重的同步机制（比如自旋锁或 seqlock）。实测在 64+ 核机器上，这种争用会使 sched 路径延迟上升 15% 以上。
而尾部是“冷区”：批量入队（如 goready 批量唤醒）时堆积的 Goroutine，延迟几微秒被偷走，对延迟敏感型任务（如 HTTP handler）影响极小。
- 目标 P 的入队（
runqput）写 tail，出队（runqget）读 head，天然分离 - 窃取方只读 tail 并尝试更新 head，不干扰入队路径
- 这使得
runq在无锁前提下支持并发 push/pop + steal，是 Go 调度器低延迟的关键
steal 失败后没有日志，但有可观测信号
你不会看到 “steal failed” 或 “no work to steal” 这类日志——runqsteal 失败直接返回 nil，findrunnable 继续 fallback 到全局队列，或者最终让 M 解绑 P 进入休眠。
真正要盯住的是间接指标：
- 大量 Goroutine 积压在全局队列（可通过
runtime.ReadMemStats查NGC和NumGoroutine差值粗略估算） - P 频繁进入 spinning 状态（
runtime.NumGoroutine()稳定但 CPU 使用率持续低于预期） - 提升
GOMAXPROCS后吞吐不增反降，尤其在 CPU 密集型场景下
这些现象往往指向：窃取失败率高 → 全局队列争用加剧 → sched.lock 成为瓶颈。这不是代码写得不对，而是 P 数量与 workload 特征不匹配的真实反馈。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
