Go 1.14+ 通过 SIGURG 信号实现异步抢占，解决纯计算循环独占 P 导致其他 goroutine 饿死的问题；但仅在安全点生效，for {} 等无函数调用场景仍需手动插入 runtime.Gosched() 才能可靠让权。
因为纯计算密集型 for {} 在 Go 1.13 及之前会彻底卡死调度器，导致同 P 上其他 goroutine 饿死——这不是性能问题，而是调度逻辑缺陷。
Go 1.13 及之前：协作式调度的致命盲区
调度器完全依赖 goroutine 主动让出控制权，比如：
- 调用函数（哪怕空函数）→ 编译器在入口插入检查点
- 执行 channel 操作、系统调用、GC 扫描点
- 显式调用
runtime.Gosched()
但像 for { i++ } 这种无函数调用、无栈增长、无阻塞点的循环，在 1.13 中一旦开始运行，就会独占整个 P，其他 goroutine 根本得不到调度机会。trace 里能看到单个 G 的 running 区段持续几百毫秒甚至数秒，gwait 持续上涨。
Go 1.14+：用 SIGURG 强行“拽下来”
核心机制是 sysmon 线程每 ~20ms 检查各 P 的运行时长，发现某个 G 在 P 上连续运行超 ~10ms 后，调用 signalM 向对应 OS 线程（M）发送 SIGURG 信号。M 收到后在下一个安全点暂停当前 G，将其状态设为 _gpreempted 并放回队列。
立即学习“go语言免费学习笔记（深入）”；
注意几个关键事实：
- 不是实时打断：必须等指令流到达安全点（如函数返回前、栈检查处），纯内联算术循环仍可能逃逸
- 不保证立即切换：被抢占的 G 进入队列后，要等下次调度才可能被其他 M 拿走
- 信号可能丢弃：若 M 正陷在系统调用中、处于不可中断睡眠（D 状态）、或 signal mask 屏蔽了
SIGURG，抢占就失效
为什么还必须手动加 runtime.Gosched()？
因为异步抢占不是兜底方案，而是补漏机制。以下场景它大概率不生效：
-
for {}内联了纯计算（sum += i * j），且未触发任何函数调用或栈操作 - 调用
runtime.LockOSThread()后的死循环 - CGO 调用期间（Go 调度器完全交出控制权）
- 某些 runtime 底层汇编函数（如
memclrNoHeapPointers）被标记为go:nosplit
这时候 runtime.Gosched() 是唯一语义明确、开销低、行为确定的让权方式。别每轮都调，建议按迭代次数控制，比如 if i%1024 == 0 { runtime.Gosched() }。
验证抢占是否真起作用，别靠“程序好像没卡住”
真实判断必须看调度痕迹：
- 加环境变量启动：
GODEBUG=schedtrace=1000 go run main.go，观察输出中gwait是否持续上涨 - 用
go tool trace：确认编译期已插桩（go run -gcflags="-S" main.go 2>&1 | grep preempt），运行后搜Preempted事件，或看某 G 的running区段是否被切成多段 - 写对照测试：一个
for {}+ 十个time.Sleep(1 * time.Millisecond); fmt.Println(time.Now())，后者若能在几毫秒内轮流打印，说明抢占基本在线
最容易被忽略的是信号链路是否完整：从 sysmon → signalM → tgkill → 目标 M 的 signal mask → 用户态响应。任何一个环节断掉，抢占就静默失败，而你根本不会收到错误提示。
