Go 1.14+ 通过 SIGURG 信号实现异步抢占，使空 for 循环不再阻塞调度器；需确保 Linux 默认启用、未关闭 GODEBUG 且平台支持，否则抢占可能失效。
为什么空 for 循环不再卡死调度器（Go 1.14+）
Go 1.14 起，for { i++ } 这类纯计算循环不会再让整个 P 长期霸占 CPU、阻塞其他 goroutine —— 因为调度器终于能“硬抢”了。这不是靠函数调用栈检查（如 morestack），而是靠操作系统信号（SIGURG）中断正在运行的 M 线程，强制它把当前 G 暂停并交出控制权。
关键前提是：Linux 上默认启用，且不被 GODEBUG=asyncpreemptoff=1 关闭；ARM64 等部分平台可能仍不支持（preemptMSupported == false）。
- 现象上，你不会看到 GC STW 卡住、pprof trace 里某个 G 一直
running超过 10ms - 但代价是：信号处理会引入微小开销，且可能让原本不触发
EINTR的系统调用（如read）意外返回EINTR - 若你在调试中发现某个 P 死活不响应抢占，先用
dlv查goroutines，再确认该 M 是否被挂起在 sigmask 阻塞状态（比如用pthread_sigmask手动屏蔽了SIGURG）
如何验证异步抢占是否真正生效
别只信文档，用 runtime/debug.SetTraceback("all") + go tool trace 最直接。在 trace 中找 Preempted 事件，或观察某 G 的执行片段是否被明显切碎（比如一个长循环被拆成多个 running 区段，中间夹着 runnable → running 切换）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 写个测试程序：启动一个
for {}goroutine，再起 10 个打印时间戳的 goroutine，看后者能否在几毫秒内被调度 - 用
go run -gcflags="-S" main.go 2>&1 | grep preempt可确认编译期是否注入抢占检查点（1.14+ 默认开启） - 若 trace 里完全看不到
Preempted，检查是否启用了GODEBUG=asyncpreemptoff=1，或运行环境不满足（如容器内禁用信号）
抢占失败的典型现场和排查路径
最常见的“假死”不是调度器坏了，而是信号根本没送达或被忽略。比如：sysmon.preemptall 调用 signalM → tgkill 发送 SIGURG，但如果目标 M 正在执行原子指令（如 LOCK 前缀指令）、处于内核态不可中断睡眠（D 状态）、或其 signal mask 显式屏蔽了 SIGURG，信号就会丢弃。
立即学习“go语言免费学习笔记（深入）”；
- 用
strace -p <pid> -e trace= tgkill,sigprocmask</pid>观察信号是否发出、是否被屏蔽 - core dump 中查
runtime.sigmask和m.sigmask，确认SIGURG位是否为 0（即未屏蔽） - 某些 CGO 场景下，C 代码调用
pthread_sigmask后未恢复，会导致后续 Go 代码收不到抢占信号 —— 这类问题必须从 C 层修复
对 defer 和 timer 的连带影响（容易被忽略）
异步抢占上线后，defer 内联优化和 time.Timer 改进其实共享同一套底层机制：更细粒度的调度时机控制。抢占越及时，GC 的 STW 阶段就越短，defer 的栈帧复用率越高，timer 堆的轮询也越不容易被长循环拖累。
- 但反过来说，如果某个 goroutine 频繁触发抢占（比如每 10ms 就被中断一次），它的
defer调用链可能被切在非预期位置，导致 panic 栈更碎片化 -
time.AfterFunc在高抢占压力下，回调延迟方差可能略增（微秒级），不是 bug，是调度公平性的代价 - 真正要警惕的是：别在信号 handler（
doSigPreempt）附近做任何非异步信号安全的操作 —— 它运行在 M 的信号栈上，此时 malloc、lock、printf 全都不安全
strace + dlv + core 三件套一层层剥。 
