go 的 goroutine 调度器不保证公平性或随机性，其行为由底层实现、gomaxprocs、硬件环境及代码中是否主动让出（如 runtime.gosched）共同决定——这导致看似并发的消费逻辑在多次运行中呈现惊人稳定的分配比例。
go 的 goroutine 调度器不保证公平性或随机性，其行为由底层实现、gomaxprocs、硬件环境及代码中是否主动让出（如 runtime.gosched）共同决定——这导致看似并发的消费逻辑在多次运行中呈现惊人稳定的分配比例。
在 Go 并发编程中，一个常见误区是认为多个 goroutine 同时从同一个 channel 读取数据会“自动均衡”地分摊任务。但事实恰恰相反：channel 的接收操作本身不是原子调度点，goroutine 的执行顺序和资源抢占高度依赖调度器的内部策略与运行时上下文。
以原始示例为例：
producer := make(chan int)
// 两个消费者 goroutine 同时 range producer
go func() { /* consumer 1 */ }()
go func() { /* consumer 2 */ }()这里存在两个关键问题：
无缓冲 channel 导致强耦合：producer 是无缓冲 channel，每次 producer <- i 必须等待至少一个消费者就绪才能完成。但谁先抢到这次接收权，取决于调度器在那一刻的状态——而该状态在固定环境（相同 GOMAXPROCS、单核/多核、无干扰负载）下具有高度可复现性。
缺乏显式让出点（yield point）：goroutine 在 tight loop（如密集的 range 接收）中若不主动调用 runtime.Gosched() 或执行 I/O、channel 操作等调度点，可能持续占用 M（OS 线程），造成“饥饿式”执行。实验表明，在 Go 1.4–1.6 中，默认 GOMAXPROCS=1（单线程调度）时，第一个启动的消费者 goroutine 极易持续抢占接收权，直到被调度器强制中断（例如因系统调用或垃圾回收），从而形成约 2:1 的稳定分配比（如 667 vs 333）。
✅ 正确做法不是依赖“运气”，而是显式控制并发语义：
- ✅ 使用带缓冲 channel（如 make(chan int, 64)）降低发送端阻塞耦合；
- ✅ 为消费者添加 runtime.Gosched() 或 time.Sleep(0) 强制让出，提升调度公平性；
- ✅ 更重要的是：避免多个 goroutine 竞争同一 channel 的消费权——这本质上违背了 Go “不要通过共享内存来通信，而应通过通信来共享内存”的哲学。
推荐重构方式（语义清晰、行为可预测）：
package main
import "fmt"
func main() {
producer := make(chan int, 100)
done := make(chan bool, 2)
// 启动生产者
go func() {
for i := 0; i < 1000; i++ {
producer <- i
}
close(producer)
}()
// 两个独立消费者（无竞争）
go func() {
count := 0
for range producer {
count++
}
fmt.Printf("Consumer 1: %d\n", count)
done <- true
}()
go func() {
count := 0
for range producer {
count++
}
fmt.Printf("Consumer 2: %d\n", count)
done <- true
}()
<-done; <-done // 等待全部完成
}⚠️ 注意：即便如此，由于 range 在 channel 关闭后仍会消费所有已入队数据，两个消费者实际共享了全部 1000 个值——但谁读到哪个值仍是不确定的。若需真正并行分片处理，应由生产者主动分发（如轮询发送至不同 consumer channel），或使用 sync.WaitGroup + 显式任务切分。
总结：Go 调度器的设计目标是高效而非公平；其行为在相同环境下具有强可复现性，但这恰恰是“未定义行为”的体现。编写健壮并发程序的核心原则是——永远假设调度是不可预测的，并通过 channel 结构、同步原语和明确的责任划分来消除对调度顺序的隐式依赖。
