Golang深度解析Go-Scheduler如何抢占Goroutine以及语言学习原理

作者：袖梨 2026-07-20

Go 1.14+ 抢占式调度需满足安全点、信号可达、M处于用户态等条件才能生效；纯计算循环、CGO调用、系统调用阻塞等场景下runtime.preemptM常静默失败，G仍会长期霸占P。

Go 1.14 起确实支持非协作式抢占，但「能抢占」不等于「总能抢到」——纯计算循环、CGO 调用、系统调用阻塞、汇编函数绕过等场景下，runtime.preemptM 很可能静默失败，G 仍会长期霸占 P。

抢占触发条件：不是超时就中断，而是得落在安全点上

Go 的抢占不是在任意指令处打断，必须等到 Goroutine 主动进入「安全点」（safepoint）。常见安全点包括：

函数调用返回前（如 call 指令后、ret 前的 runtime 插桩）
栈增长检查（morestack_noctxt）
GC 扫描过程中对 Goroutine 栈的遍历
channel 操作、select、time.Sleep 等运行时介入点

这意味着一个没有函数调用、不碰栈、不触发任何 runtime hook 的死循环：for { i++ }，在 Go 1.20 及之前几乎无法被抢占；直到 Go 1.21 引入 asyncPreempt 插桩（默认开启），才在更多指令边界插入异步抢占检查。

sysmon 如何发现并发起抢占

sysmon 是一个后台 M，每约 20ms 轮询所有 P，比对 p.schedtick（调度计数）和 p.sysmontick（上次 sysmon 检查时间戳）。若发现某 G 在同一 P 上连续运行超过 ~10ms（实际阈值为 forcegcperiod = 2ms × 5，默认 10ms），则向对应 M 发送 SIGURG 信号。

立即学习“go语言免费学习笔记（深入）”；

关键限制：

信号只发给用户态且未屏蔽 SIGURG 的 M；若 M 正在执行系统调用（如 read、epoll_wait），信号会延迟到返回用户态才处理
若该 G 当前状态是 _Gsyscall 或 _Gwaiting（比如刚进 syscall、或在 channel 上阻塞），preemptM 直接返回 false，不发信号
sysmon 不负责切换，只设 G 状态为 _gpreempted，之后由调度器下次 pickgoroutine 时将其放回本地或全局队列

为什么 `runtime.preemptM` 有时没反应

调用 runtime.preemptM 后无效果，常见原因不是 API 用错，而是目标 M 不满足响应条件：

目标 M 正在 CGO 调用中（Go 1.22 前默认禁用 CGO 中的抢占插桩，且 M 可能脱离 Go 调度器管理）
目标 G 处于 _Gsyscall 或 _Gwaiting 状态，抢占逻辑直接跳过
目标 M 屏蔽了 SIGURG（例如被 C 代码修改 sigmask）
目标 G 正在执行标记为 //go:nosplit + //go:noinline 的汇编函数（如 memclrNoHeapPointers），跳过所有抢占检查

验证方式：启用 GODEBUG=schedtrace=1000 观察调度 trace，看对应 G 是否出现 preempted 状态；或用 pprof 查看 goroutine stack 是否卡在纯计算路径上。