Golang调度器异常问题：Linux与Mac OS X表现差异

我之前也碰到过类似的跨平台调度差异问题，这种情况本质上是Go调度器在不同操作系统下的实现策略差异导致的，咱们一步步拆解清楚：

问题核心原因 #

首先得明确runtime.Gosched()的真实作用：它只是建议Go调度器把当前goroutine的CPU时间片让给其他等待的goroutine，但调度器是否真的执行切换，完全由底层的调度策略决定——而Linux和macOS的Go调度器实现细节存在差异，这就是问题的根源。

你提到的log.Printf()能"修复"问题，并不是因为它和Gosched()有什么直接关联，而是因为log.Printf()内部会触发系统调用（向标准输出写入数据）。Go的调度器在遇到系统调用时，会自动把当前goroutine从绑定的M（操作系统线程）上解绑，让P（逻辑处理器）去调度其他等待的goroutine——这就间接帮接收消息的goroutine抢到了运行机会。

在macOS上，调度器的切换策略更积极，即使没有额外的系统调用触发，runtime.Gosched()的建议也会被采纳；但在Linux下，如果当前goroutine的操作足够轻量（比如你的循环里只是休眠+发通道），调度器可能会忽略Gosched()的建议，让主goroutine继续占用CPU，导致接收goroutine一直没机会运行。

复现代码验证 #

先贴一个能复现你问题的最简代码：

package main

import (
	"log"
	"runtime"
	"time"
)

func main() {
	ch := make(chan struct{})

	go func() {
		count := 0
		for range ch {
			count++
		}
		log.Printf("最终收到消息数: %d", count)
	}()

	for i := 0; i < 1000; i++ {
		time.Sleep(1 * time.Millisecond)
		ch <- struct{}{}
		// 注释掉下面这行，Linux下可能收到的消息数远小于1000
		// log.Printf("已发送第%d条消息", i)
		runtime.Gosched()
	}

	close(ch)
	// 这里如果不加休眠，主goroutine直接退出，接收goroutine可能还没跑完
	time.Sleep(1 * time.Second)
}

正确的解决方案 #

不要依赖runtime.Gosched()这种手动触发调度的方式，Go的并发模型本身就提供了更可靠的同步机制，推荐用sync.WaitGroup来确保所有goroutine完成工作，同时利用通道本身的同步特性触发调度：

package main

import (
	"log"
	"sync"
	"time"
)

func main() {
	ch := make(chan struct{})
	var wg sync.WaitGroup

	// 标记需要等待的goroutine数量
	wg.Add(1)
	go func() {
		defer wg.Done() // 完成后通知WaitGroup
		count := 0
		for range ch {
			count++
		}
		log.Printf("最终收到消息数: %d", count)
	}()

	for i := 0; i < 1000; i++ {
		time.Sleep(1 * time.Millisecond)
		ch <- struct{}{}
	}

	close(ch)
	wg.Wait() // 等待接收goroutine处理完所有消息再退出
}

这个方案在Linux和macOS下都能稳定工作：

1. 无缓冲通道的发送操作本身会触发调度（发送方会阻塞直到接收方处理），确保接收goroutine有机会运行；
2. sync.WaitGroup避免了主goroutine提前退出，保证接收goroutine能处理完所有消息。

内容的提问来源于stack exchange，提问作者rampatowl