Go 语言中 runtime 调度器如何处理长时间运行的协程

先说一个核心判断：Go 调度器并不会像操作系统那样，靠时间片来强制中断一个正在运行的协程。它走的是协作式路线——依赖协程自己主动“让出”。那么，问题来了：如果一个协程埋头做纯计算，死活不触发任何调度点，会发生什么？答案是，其他 goroutine 可能会被活活饿死，尤其是在抢占机制还没反应过来的时候。

Go 调度器不会靠时间片强制中断协程，而是依赖“安全点”主动让出；长时间纯计算循环（如密集原子操作或空 for 循环）仍可能饿死其他 goroutine，尤其在未触发抢占的间隙期。

哪些情况算“长时间运行”且调度器难介入？

这里的“长时间”不是指你盯着手表看了几秒钟，而是指未到达任何协作式调度点（safepoint）的连续 CPU 占用。典型场景包括：

• for { atomic.AddUint64(&counter, 1) }：原子操作是内联汇编指令，不调用函数、不分配内存、不触发栈增长，完全绕过所有 safepoint
• for i := 0; i < N; i++ {}：纯算术循环，无函数调用（尤其当编译器内联/优化掉边界检查时），Go 1.14+ 的异步抢占默认每 10ms 才尝试一次，期间 P 被独占
• for { select {} }：空 select 是永久阻塞，但它是显式等待语义，调度器会立即将 G 挂起——这反而是安全的，不属于“长时间运行”的问题范畴

Go 1.14+ 的异步抢占机制到底管不管用？

它管，但有明确边界：

• 抢占信号（SIGURG）只对“已运行超阈值”的 goroutine 生效，默认 10ms，且仅在函数调用返回前、GC 辅助工作、栈扩容等少数位置插入检查点
• 单条 atomic.AddUint64 或紧邻的几条算术指令，远低于抢占触发条件，不会被中断
• 即使触发抢占，也只是将当前 G 标记为“可被调度”，不保证立刻切换——若本地队列无其他就绪 G，它可能马上又被选中继续跑
• 抢占本身有开销，频繁触发反而增加抖动，不是设计用来兜底 tight loop 的

runtime.Gosched() 是救急手段，不是调度策略

它只是把当前 G 放回本地运行队列尾部，不休眠、不挂起、不释放 P，下一轮仍可能被立即调度。它的适用前提是：

• 你确实在写自旋逻辑，且无法用 chan、time.Sleep 或 sync.Cond 替代
• 循环体中无临界区或未完成的数据一致性操作（比如刚写完共享变量还没刷出去，就 Gosched()，其他 G 可能读到脏数据）
• 调用频率合理：例如每处理 1000–10000 项后一次，而非每轮都调——否则等于手动制造高频调度风暴
• 你已确认这不是 I/O 阻塞、锁竞争或 GOMAXPROCS 过小导致的假性“卡顿”

真正该优先考虑的替代方案

绝大多数所谓“长时间运行”问题，根源不在调度器懒，而在代码没用对 Go 的并发原语：

• 用 time.Sleep(1 * time.Nanosecond) 替代 runtime.Gosched()：语义清晰（真暂停）、兼容性好、新版 Go 中也更可靠
• 把大任务切块，每块处理完向 chan struct{} 发一个信号，由主 goroutine 控制节奏——天然带调度点
• 涉及共享状态的自旋，必须配 atomic.Load* 或 sync/atomic 读取，否则编译器可能优化掉重复读，让你永远看不到更新
• 排查是否误用了 runtime.LockOSThread() 或 GOMAXPROCS(1)，它们会让调度器失去弹性空间

最易被忽略的一点：调度延迟往往不是“协程跑太久”，而是“其他协程根本没被分发到本地队列”。比如压测初期大量 goroutine 堆在全局队列（GRQ），P 要等本地队列（LRQ）空了才去搬，中间最多延迟 61 次调度间隔——这时候加 Gosched() 没用，得控制 goroutine 创建节奏或复用 worker pool。