Go语言协程执行顺序为何难以预测？

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: %dn", i)
            } else {
                fmt.Printf("b: %dn", 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 1.5版本发布说明已明确指出，协程调度的具体行为并非语言规范的一部分。尽管Go运行时会努力优化调度，但我们绝不能依赖任何特定的执行顺序。

第一个循环中，所有协程都闭包引用了同一个变量i。当协程真正执行时，i的值已经是循环结束后的值5了。这导致所有打印"a:"的协程都打印"a: 5"。第二个循环则通过参数传递避免了这个问题。

因此，"b: 4"可能先打印并非由于队列机制，而是Go协程调度固有的非确定性。即使"b: 4"的协程是最后创建的，我们也无法预测哪个协程会先执行。依赖Go协程的特定执行顺序是一种危险的编程实践。编写健壮的Go程序，务必避免依赖未定义的行为。