go 1.14+ 抢占式调度通过 sigurg 信号在安全点强制中断 os 线程以切换 goroutine；验证需用 schedtrace 或 go tool trace 观察 preempted 事件；asyncpreempt 在纯内联死循环等场景仍可能失效，故 runtime.gosched() 仍是必要保险；抢占失败多因信号被屏蔽或 m 处于不可中断状态，应逐环节排查。
Go 1.14+ 的抢占式调度不是“让 goroutine 主动交权”，而是系统在它不交权时，硬把它拽下来——靠的是 SIGURG 信号中断正在跑的 OS 线程（M），强制切走当前 goroutine（G）。但它只在“安全点”生效，不是任意指令都能打断。
怎么验证你的 for {} 真被抢了？别猜，看 trace
空循环是否还卡死调度器，不能靠“程序好像没卡住”来判断。最直接的方式是抓运行时调度痕迹：
- 加环境变量启动：
GODEBUG=schedtrace=1000 go run main.go，观察输出中gwait是否持续上涨（涨说明 goroutine 堆积，没被调度） - 用
go tool trace：先go run -gcflags="-S" main.go 2>&1 | grep preempt确认编译期插桩已启用；再运行时加runtime/trace.Start，打开 trace 页面后搜Preempted事件，或看某 G 的running区段是否被切成多段（中间夹着runnable → running） - 写个对照测试：一个
for {}，另起 5 个time.Sleep(1 * time.Millisecond); fmt.Println(time.Now())，如果后者能在几毫秒内轮流打印，说明抢占基本生效
为什么 runtime.Gosched() 还得手动加？asyncpreempt 不是万能的
asyncpreempt 能打断长循环，但前提是 CPU 指令流里存在可插入信号处理的安全上下文。纯内联算术（i++、a += b * c）、无函数调用、无栈操作的死循环，在 Go 1.20 及更早版本仍可能逃逸抢占——直到 1.21 加强插桩才大幅缓解。
- 常见失效场景：
for { sum += i; i++ }（无调用）、runtime.LockOSThread()后的循环、CGO 调用中、或GODEBUG=asyncpreemptoff=1显式关闭 -
runtime.Gosched()是明确让出控制权的“保险丝”：它把当前 G 放回全局队列，下次调度时再拿，开销低且语义确定 - 别每轮都调——在 hot loop 里按迭代次数控制，比如
if i%1024 == 0 { runtime.Gosched() } - 慎用
runtime.osyield()：它只提示 OS 让出时间片，不参与 goroutine 调度，对唤醒其他 G 几乎没帮助
抢占失败，八成是信号没送到——查 sigmask 和 strace
抢占逻辑是：sysmon 发现某个 G 在 P 上跑了超 10ms → 调用 signalM → 用 tgkill 向对应 M 发 SIGURG。但若目标 M 的 signal mask 屏蔽了该信号，或者它正陷在系统调用/内核态不可中断睡眠中，信号就丢弃了。
- 用
strace -p <pid> -e trace=tgkill,sigprocmask</pid>观察：有没有tgkill发出？有没有sigprocmask把SIGURG给 block 了？ - CGO 场景下尤其危险：C 代码调用
pthread_sigmask后未恢复，会导致后续所有 Go 代码收不到抢占信号——必须从 C 层修复 - 调试时若发现某个 M 长期不响应，用
dlv查goroutines，再看其m.sigmask中SIGURG对应位是否为 0（即未屏蔽） - 某些容器环境会默认禁用
SIGURG，需检查容器配置或 seccomp profile
真正难搞的不是“怎么开抢占”，而是“为什么它没生效”。信号路径上的每个环节——从 sysmon 判定、到 tgkill 发送、再到 M 的 signal mask 和执行状态——都可能断掉。别一上来就怀疑调度器坏了，先确认信号到底有没有发出去、有没有被挡住。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
