理解sourcegraph/conc中的并发陷阱：循环变量捕获问题

在使用sourcegraph/conc库进行并发编程时，开发者可能会遇到一个常见的Go语言并发陷阱——循环变量捕获问题。这个问题不仅出现在conc库中，也是Go并发编程中需要特别注意的一个关键点。

问题现象

当开发者在循环中使用conc.WaitGroup启动goroutine时，如果直接引用循环变量，可能会导致意外的行为。例如，在循环中启动多个goroutine，每个goroutine都试图使用当前的循环索引值，但最终所有goroutine可能都使用了相同的值（通常是循环结束时的最终值）。

问题本质

这种现象的根本原因在于Go语言中循环变量的作用域和生命周期。在Go中，循环变量（如for循环中的i）在每次迭代中是被重用的，而不是为每次迭代创建新的实例。当在goroutine中捕获这个变量时，实际上捕获的是变量的内存地址，而不是当时的值。

由于goroutine的调度是非确定性的，当goroutine真正执行时，循环可能已经继续执行了多次，此时捕获的变量值可能已经改变。这就导致了所谓的"数据竞争"——多个goroutine并发访问同一内存位置，其中至少有一个是写操作。

解决方案

解决这个问题的方法很简单：在循环内部创建一个局部变量副本。这样每个goroutine都会捕获自己独立的变量副本，而不是共享同一个循环变量。

for i := 0; i < 10; i++ {
    i := i // 创建局部副本
    wg.Go(func() {
        countF(i) // 现在每个goroutine都有自己的i副本
    })
}

或者将循环变量作为参数传递给闭包：

for i := 0; i < 10; i++ {
    wg.Go(func(id int) func() {
        return func() {
            countF(id)
        }
    }(i))
}

深入理解

这个问题之所以容易被忽视，是因为在顺序编程中，类似的代码不会出现问题。但在并发环境下，goroutine的执行时机是不确定的，这就放大了变量捕获的问题。

sourcegraph/conc库的WaitGroup虽然提供了方便的并发控制机制，但它并不能自动解决这类语言层面的并发陷阱。开发者仍然需要理解Go的并发模型和变量作用域规则。

最佳实践

1. 在循环中启动goroutine时，总是显式地创建循环变量的副本
2. 考虑使用函数参数传递的方式，而不是直接捕获循环变量
3. 使用工具如go vet或-race标志来检测潜在的数据竞争
4. 在复杂的并发场景中，考虑使用更高级的同步原语或并发模式

理解并正确处理这类问题，是编写正确、高效并发程序的基础。sourcegraph/conc这样的库虽然简化了并发控制，但开发者仍需对Go的并发模型有深入理解，才能充分发挥其优势。