纯原子循环必须加 runtime.Gosched，因为 atomic.AddUint64 是内联汇编指令，不触发调度器安全点，会导致 goroutine 饿死其他任务；Gosched 是唯一可控的显式让出点，仅协作式让出 CPU 而不休眠或释放锁。
为什么纯原子循环必须加 runtime.Gosched
因为 atomic.AddUint64 是内联汇编指令，不触发任何函数调用、不访问栈、不分配内存——它完全绕过 Go 调度器的所有安全点。当写成 for { atomic.AddUint64(&x, 1) }，该 goroutine 就会死锁整个 P：其他 goroutine（包括主 goroutine 的 fmt.Println 或 time.Sleep）永远得不到执行机会。
- Go 1.14+ 虽引入异步抢占，但默认每 10ms 检查一次，且对单条原子指令不生效
-
runtime.Gosched()是唯一可控的显式让出点，它把当前 goroutine 放回本地运行队列尾部，立即触发下一轮调度 - 它不休眠、不挂起、不释放锁，只是“松开 CPU”，语义上等价于协作式 yield
哪些场景真需要手动调用 Gosched
绝大多数 Go 代码根本不需要它——channel、time.Sleep、net.Conn.Read、甚至普通函数调用都会自动触发调度。只有以下极少数情况才应考虑：
- 手写自旋等待逻辑，且无法改用
sync.Cond或带超时的select - 遍历超大 slice 做密集计算（如校验千万级数据），且循环体内无任何函数调用或内存操作
- 嵌入式或实时系统中需微调响应延迟，且已确认标准阻塞原语不可用
- 教学演示调度行为（生产环境慎用）
常见误用：for { select {} } 加 runtime.Gosched() 无效——它仍是死循环，应改用 time.Sleep(0) 或带默认分支的 select。
Gosched 不是 sleep，也不能替代 channel
runtime.Gosched() 和 time.Sleep(0) 行为完全不同：前者只是让出本轮时间片，下一轮仍可能被立刻选中；后者会让 goroutine 进入定时器等待队列，真正释放 P 给其他 goroutine 使用。
- 它不解决内存可见性问题：自旋读共享变量时，仍需
atomic.LoadUint64或sync/atomic原语 - 它不释放 mutex、不暂停 timer、不影响 defer 执行顺序
- 频繁调用会制造不必要的调度抖动，反而降低吞吐；建议按批次控制，例如每处理 10000 次原子操作后调用一次
Go 1.14+ 后 Gosched 还有必要吗
不是“没必要”，而是“更少必要”——异步抢占机制大幅降低了纯计算循环饿死其他 goroutine 的概率，但它仍有局限：
- 抢占信号（SIGURG）有延迟，默认 10ms，短时密集循环仍可能卡住 P
- 编译器内联优化可能消除本可用于抢占的函数调用点
- 某些低功耗设备或特殊构建环境下，抢占可能被禁用
所以生产代码中，若你明确知道某段逻辑会长期占用 CPU 且无天然阻塞点，加一行 runtime.Gosched() 仍是简单、低成本、可预期的保险措施。但别把它当成通用调度工具——优先用 channel 控制节奏，用 time.Sleep 实现等待，这才是 Go 的惯用法。
