go 1.14+ 异步抢占依赖 sigurg 信号与安全点协同，缺一不可；信号仅通知，真正抢占需等待下个安全点，常见失效因信号屏蔽、无安全点、cgo 脱离调度或系统调用阻塞。
Go 1.14+ 的异步抢占不是“发个信号就立刻切走”，它依赖 SIGURG 信号 + 安全点（safepoint）双重配合；信号可能被屏蔽、安全点可能根本不存在，两者缺一不可。
为什么 SIGURG 发了但 goroutine 还是卡死？
信号只是“通知”，真正让出控制权必须等到下一次安全点。常见失效场景包括：
-
runtime.LockOSThread()后，M 的 signal mask 很可能屏蔽了SIGURG，信号直接丢弃，strace -e trace=rt_sigprocmask,rt_tgsigqueueinfo可验证 - 纯寄存器循环（如
for { i++ }）在 Go 1.20 及更早版本中几乎不生成安全点；即使 Go 1.21+ 增强插桩，若函数被内联且无内存访问/分支，仍可能逃逸 - CGO 调用期间 M 脱离 Go 调度器管理，
SIGURGhandler 不生效；Go 1.22 前默认禁用 CGO 中的抢占插桩 - 系统调用阻塞时（如
readhang），信号无法送达用户态，只能等返回——而此时可能已过去数秒
sysmon 触发抢占的两个硬性条件
sysmon 每约 20ms 轮询一次所有 P，但只对同时满足以下两点的 P 才调用 preemptone：
- P 状态为
_Prunning（即正执行用户 goroutine，非 GC 或 syscall） - 该 P 连续运行 ≥ 10ms（通过
_p_.schedtick和时间戳比对判定）
注意：sysmon 不会轮询 _Psyscall 或 _Pgcstop 状态的 P；也不会重试发送失败的 SIGURG——投递失败即终止流程。
如何确认 asyncPreempt 真正在工作？
别看程序“没卡住”，要抓运行时证据：
- 加
GODEBUG=schedtrace=1000运行，紧盯输出中gwait列：持续上涨说明 G 积压未被调度，抢占大概率失效 - 用
go tool trace，先确认编译期插桩启用（go run -gcflags="-S" main.go 2>&1 | grep preempt），再搜Preempted事件，或观察某 G 的running区段是否被切成多段（中间有runnable → running切换） - 写最小对照：一个
for {}+ 5 个time.Sleep(1 * time.Millisecond)打印时间戳；若后者能在 ~2–3ms 内全部执行完，说明抢占基本在线
runtime.Gosched() 为什么仍是必要保险？
asyncPreempt 是尽力而为，runtime.Gosched() 是明确语义的让出：
- 它强制将当前 G 放回全局队列，下次调度必重新排队，行为确定、开销低
- 在 hot loop 中建议按迭代次数控制，例如
if i%1024 == 0 { runtime.Gosched() }，而非每轮都调 - 它在
//go:nosplit函数、GC 临界区、纯寄存器循环里依然有效——因为它是主动调用，不依赖信号和安全点
最容易被忽略的是：抢占失败往往不是调度器坏了，而是信号根本没送达；查不到 Preempted 事件，第一反应不该是改代码逻辑，而是先用 strace 看 SIGURG 是否被屏蔽或丢弃。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
