本文探讨了在 Go 语言并发编程中，循环次数的奇偶性对 Goroutine 执行结果的影响。通过一个示例代码，展示了当循环次数为偶数时，部分数据可能无法被 Goroutine 处理的现象。分析了这种现象背后的原因，并提供了使用 `sync.WaitGroup` 确保 Goroutine 完成的解决方案。
在 Go 语言中，并发编程是其核心特性之一。然而，并发程序的行为往往受到调度器的影响，可能出现一些看似随机的现象。本文将深入探讨一个有趣的案例：当使用 Goroutine 处理数据时，循环次数的奇偶性竟然会影响最终结果。
问题描述
以下 Go 代码片段展示了这个问题：
package main
import "runtime"
func main() {
c2 := make(chan int)
go func() {
for v := range c2 {
println("c2 =", v, "numof routines:", runtime.NumGoroutine())
}
}()
for i := 1; i <= 10001; i++ {
c2 <- i
//runtime.Gosched()
}
}这段代码创建了一个 Goroutine，用于从 channel c2 中读取数据并打印。主 Goroutine 向 c2 中发送一系列整数。
奇怪的是，当循环次数为奇数（例如 10001）时，代码能够正确输出所有数字。但当循环次数为偶数（例如 10000）时，最后一个数字却丢失了。
原因分析
这个现象的根本原因是 Go 程序的退出机制。当 main 函数返回时，程序会立即终止，而不会等待任何 Goroutine 完成。因此，Goroutine 是否能在 main 函数返回前完成所有任务，取决于调度器的行为，以及一些随机因素和外部条件。
循环次数的奇偶性可能会影响调度器的行为，导致 Goroutine 在 main 函数返回前完成或未完成。当循环次数为偶数时，main 函数可能在 Goroutine 处理完所有数据之前就退出了，导致最后一个数据丢失。
解决方案
要解决这个问题，我们需要确保 Goroutine 在 main 函数退出前完成所有任务。一种常用的方法是使用 sync.WaitGroup。
package main
import (
"fmt"
"runtime"
"sync"
)
func main() {
c2 := make(chan int)
var wg sync.WaitGroup
wg.Add(1) // 增加一个等待的 Goroutine
go func() {
defer wg.Done() // Goroutine 完成后，减少等待计数
for v := range c2 {
fmt.Println("c2 =", v, "numof routines:", runtime.NumGoroutine())
}
}()
for i := 1; i <= 10000; i++ {
c2 <- i
}
close(c2) // 关闭 channel，通知 Goroutine 停止接收数据
wg.Wait() // 等待所有 Goroutine 完成
}在这个修改后的版本中，我们使用了 sync.WaitGroup 来跟踪 Goroutine 的完成状态。
- wg.Add(1) 增加了一个等待的 Goroutine。
- defer wg.Done() 在 Goroutine 完成后，减少等待计数。
- close(c2) 关闭 channel，通知 Goroutine 停止接收数据。 必须关闭channel，否则range会一直阻塞等待新的数据，导致wg.Done()无法执行，程序会hang住。
- wg.Wait() 等待所有 Goroutine 完成。
通过使用 sync.WaitGroup，我们可以确保 main 函数在所有 Goroutine 完成后才退出，从而避免数据丢失的问题。
注意事项
- Channel 关闭： 在将所有数据发送到 channel 后，务必关闭 channel。这会通知 Goroutine 没有更多数据可接收，从而结束循环。
- 错误处理： 在实际应用中，应该添加错误处理机制，以应对可能出现的错误。
总结
Go 语言的并发编程功能强大，但也需要注意调度器的行为。通过理解 Goroutine 的生命周期和使用 sync.WaitGroup 等同步机制，我们可以编写出更加健壮和可靠的并发程序。这个例子也提醒我们，即使是很小的代码改动，也可能对并发程序的行为产生意想不到的影响。在编写并发程序时，务必进行充分的测试和验证，以确保程序的正确性。
