Go调度器的“长时间运行”指未达任何安全点的连续CPU占用，典型场景包括：for { atomic.AddUint64(&counter, 1) }（原子操作内联无函数调用）、纯空循环for i := 0; i

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

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

这里的“长时间”不是指 wall-clock 时间长，而是指**未到达任何协作式调度点（safepoint）的连续 CPU 占用**。典型场景包括：

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

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

它管，但有明确边界：

使用Go语言搭建家庭相册系统-相关课件

使用Go语言搭建家庭相册系统-相关课件

下载

• 抢占信号（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。