Go语言协程调度机制详解：为何执行顺序难以预测？
本文通过一个代码示例，深入剖析Go语言协程执行顺序的非确定性，以及潜在的陷阱。看似简单的代码，却能揭示Go协程调度机制的本质特性。
以下代码创建了十个协程，其中五个打印"a:"，五个打印"b:"：
package main
import (
"fmt"
"runtime"
"sync"
)
func main() {
runtime.GOMAXPROCS(1)
wg := sync.WaitGroup{}
wg.Add(10)
for i := 0; i < 10; i++ {
go func() {
defer wg.Done()
if i < 5 {
fmt.Printf("a: %d\n", i)
} else {
fmt.Printf("b: %d\n", i-5)
}
}()
}
wg.Wait()
}
你可能会预期输出结果为"a: 0, a: 1, a: 2, a: 3, a: 4, b: 0, b: 1, b: 2, b: 3, b: 4"或类似的有序序列。然而，实际运行结果常常出乎意料，例如"b: 4"可能先于其他输出打印。这并非因为Go协程调度采用简单的先进先出队列。
立即学习“go语言免费学习笔记（深入）”；
Go语言并未明确规定协程的执行顺序。Go 1.5版本发布说明已明确指出，协程调度的具体行为并非语言规范的一部分。尽管Go运行时会努力优化调度，但我们绝不能依赖任何特定的执行顺序。
第一个循环中，所有协程都闭包引用了同一个变量i。当协程真正执行时，i的值已经是循环结束后的值5了。这导致所有打印"a:"的协程都打印"a: 5"。第二个循环则通过参数传递避免了这个问题。
因此，"b: 4"可能先打印并非由于队列机制，而是Go协程调度固有的非确定性。即使"b: 4"的协程是最后创建的，我们也无法预测哪个协程会先执行。依赖Go协程的特定执行顺序是一种危险的编程实践。编写健壮的Go程序，务必避免依赖未定义的行为。
