go 1.14+ 的 for {} 不再完全卡死调度器，因引入基于信号的异步抢占机制，可在系统调用、gc 或定时器唤醒时强制调度，但对纯计算无函数调用、cgo、runtime临界区等场景仍无效。
Go 1.14+ 为什么 for {} 不再完全卡死调度器
因为运行时在 1.14 引入了基于信号的异步抢占（asynchronous preemption），让长时间不主动让出的 goroutine 也能被强制调度。这不是“修复 bug”，而是补上了协作式调度的关键短板。
典型表现：以前 for {} 会锁死整个 P，导致其他 goroutine 饿死；现在它仍会持续占用 CPU，但系统调用、GC 扫描、甚至定时器唤醒都可能触发抢占点，使其他 goroutine 得以运行。
- 抢占不是实时的——它依赖系统信号（如
SIGURG）送达，有毫秒级延迟，无法替代合理让出（runtime.Gosched()或 I/O） - 仅对“长时间运行且无函数调用”的 goroutine 有效；一旦进入函数（哪怕空函数），编译器会在入口插入抢占检查点
- Linux/macOS 支持完整异步抢占；Windows 上受限于信号模型，效果打折扣
哪些代码仍会被调度器“忽略”甚至彻底饿死
异步抢占不是万能的。以下模式下，Go 运行时依然无法安全插入抢占点，for {} 类逻辑可能让同 P 上所有 goroutine 永久停滞：
-
for {}内联了纯计算且无函数调用（如sum += i; i++）——没有栈帧、无 GC 安全点、无信号响应上下文 - 在
runtime包内部临界区（如lockOSThread()后的死循环）——抢占信号被屏蔽 - CGO 调用期间（
C.xxx()）——Go 调度器完全交出控制权，直到 C 函数返回 - 使用
GOEXPERIMENT=asyncpreemptoff环境变量禁用了抢占（调试或兼容旧行为时）
runtime.Gosched() 和 runtime.osyield() 怎么选
两者都是手动让出，但语义和开销不同：
立即学习“go语言免费学习笔记（深入）”；
-
runtime.Gosched()：建议首选。它把当前 goroutine 放回全局队列，让其他 goroutine 有机会运行；开销低，语义清晰，适用于“计算密集但需保响应”的场景（如解析大 JSON 的中间循环） -
runtime.osyield()：只提示 OS 当前线程可让出 CPU 时间片，不涉及 goroutine 调度逻辑；几乎无开销，但不保证其他 goroutine 能立刻执行，适合极短等待（如自旋锁退避） - 别在 hot loop 里每轮都调
Gosched()——它本身有微小调度成本；可按固定迭代次数（如每 1024 次）调一次
验证抢占是否生效的简单方法
别靠观察程序“好像没卡住”来判断，要用可测量的信号：
- 开启调度追踪：
GODEBUG=schedtrace=1000，看输出中gwait（等待 goroutine 数）是否稳定，而非持续飙升 - 用
pprof抓取runtime/pprof/profile?seconds=30，检查火焰图里是否有长条形的runtime.mcall或runtime.park_m堆叠——说明抢占正常触发了调度路径 - 写一个带计数器的死循环 goroutine + 另一个定期打印时间的 goroutine，观察后者是否能在 10ms 内被唤醒（默认抢占间隔约 10ms）
真正难处理的，是那些既没函数调用、又没系统调用、还绑定了 OS 线程的纯计算循环——它们绕过了所有抢占机制。这种代码必须靠设计规避，而不是等运行时救场。
