Go调度器无法可靠中断纯CPU密集死循环，因其依赖安全点（如函数调用返回、栈扩容等）触发抢占，而无函数调用的for{}或atomic操作不产生安全点；runtime.Gosched()仅协作让出，非强制切换。
runtime抢占调度**不能可靠中断纯 CPU 密集型死循环协程**，尤其当循环体内不含函数调用、栈增长、channel 操作或内存分配时。这不是 bug，而是设计使然——Go 调度器依赖「安全点」（safepoint）插入抢占检查，而紧致的算术循环或内联原子操作根本不会到达任何安全点。
为什么 for {} 或 atomic.AddUint64 循环常被调度器“忽略”？
go 的异步抢占（自 1.14 起）靠向线程发送 sigurg 信号，并在下一个安全点执行 gosched_m。但安全点只出现在：
- 函数调用返回前（包括方法调用、内置函数如
len、cap） - 栈扩容检查处（如切片追加触发增长）
- GC 辅助工作或写屏障插入点
- 某些系统调用返回路径
像 for { i++ } 或 for { atomic.AddUint64(&x, 1) } 这类代码，编译后往往就是几条汇编指令反复跳转，不触发任何上述事件。即使运行超 10ms，默认抢占阈值也形同虚设。
runtime.Gosched() 是什么，又不是什么？
它只是把当前 G 放回本地运行队列尾部，不休眠、不释放 P、不阻塞，下一轮仍可能被立即选中。它的作用是「协作让出」，不是「强制切换」。误用后果明显：
- 每轮循环都调用 → 高频调度抖动，性能反而暴跌
- 在未完成的数据更新后调用 → 其他 goroutine 可能读到中间态，引发竞态
- 替代不了真正的 I/O 或 channel 等待语义
合理用法是：批量处理时按粒度让出，例如每处理 10000 个元素一次，且确保该粒度内无跨 goroutine 数据依赖。
真正有效的缓解手段有哪些？
别指望调度器兜底。要解决饿死问题，得从结构上拆解或注入安全点：
- 用
time.Sleep(0)替代空循环 —— 它会进入_Gwaiting状态并挂起，调度器立刻可调度其他 G - 在循环中插入显式函数调用，哪怕是个空函数：
func(){}()（注意：编译器可能内联，需加//go:noinline） - 改用
select带默认分支 +time.After实现带超时的计算节拍，天然含安全点 - 对长耗时计算做分片，每片后通过 channel 发送进度或检查取消信号（
ctx.Done()）
最关键的是：不要把 GOMAXPROCS 设为 1 来“测试调度”，这会让问题更隐蔽；也不要假设 SIGURG 能覆盖所有指令流——它只覆盖有函数边界的路径。
最容易被忽略的细节
抢占不是实时的，也不是确定性的。即便触发了 SIGURG，若本地运行队列为空、全局队列也空、netpoll 无就绪事件，那个刚被标记为「可抢占」的 G 很可能下一纳秒又被同一个 M 拿起来继续跑。所谓「10ms 抢占」，指的是「最早可能被检查的时间点」，而非「保证在此时间点切换」。真正在意响应性，就得主动设计让出点，而不是等待调度器来救火。
