Go并发基础与Fan-In模式
go语言以其轻量级并发原语——goroutine和channel而闻名，极大地简化了并发编程。goroutine是go运行时管理的轻量级线程，而channel则是goroutine之间进行通信和同步的管道。fanin模式是go并发设计中的一种常见模式，它允许将多个输入channel的数据汇聚到一个单一的输出channel中，从而实现数据的多路复用。
考虑以下场景：我们有两个独立的goroutine，分别代表“Ann”和“Joe”，它们各自以随机的间隔发送消息。我们期望通过fanIn模式将它们的消息合并到一个channel中，并观察到它们的消息是异步交错出现的，而非严格同步的。
初始问题：为何看似同步？
在实践中，初次尝试实现上述场景时，开发者可能会发现一个令人困惑的现象：尽管消息发送者内部引入了随机延迟，但输出结果却呈现出严格的“锁步”行为，即“Joe 0”、“Ann 0”、“Joe 1”、“Ann 1”等，消息似乎是交替且同步地出现的。这与我们对异步行为的预期相悖。
以下是导致这种初始困惑的示例代码：
package main
import (
"fmt"
"math/rand"
"time"
)
// boring 函数模拟一个goroutine，以随机延迟发送消息
func boring(msg string) <-chan string {
c := make(chan string)
go func() { // 启动一个goroutine
for i := 0; ; i++ {
c <- fmt.Sprintf("%s %d", msg, i)
// 引入随机延迟，模拟非同步行为
time.Sleep(time.Duration(rand.Intn(1e3)) * time.Millisecond)
}
}()
return c
}
// fanIn 函数将两个输入channel的数据汇聚到一个输出channel
func fanIn(input1, input2 <-chan string) <-chan string {
c := make(chan string)
go func() {
for {
c <- <-input1 // 从input1读取并转发
}
}()
go func() {
for {
c <- <-input2 // 从input2读取并转发
}
}()
return c
}
func main() {
c := fanIn(boring("Joe"), boring("Ann"))
// 循环读取10次消息
for i := 0; i < 10; i++ {
fmt.Println(<-c)
}
fmt.Printf("You're both boring, I'm leaving...\n")
}运行上述代码，可能会得到如下输出：
Joe 0 Ann 0 Joe 1 Ann 1 Joe 2 Ann 2 Joe 3 Ann 3 Joe 4 Ann 4 You're both boring, I'm leaving...
这种输出结果表明，尽管boring函数内部使用了rand.Intn(1e3)生成随机延迟，但“Joe”和“Ann”的消息依然是严格交替出现的。
根本原因：观察窗口不足
造成这种“锁步”现象的原因并非代码逻辑错误，而是观察窗口（即循环次数）太小。rand.Intn(1e3)会在0到999毫秒之间生成一个随机延迟。在仅有10次循环的情况下，两个boring goroutine的初始随机延迟可能非常接近，或者虽然有差异，但不足以在短时间内累积出显著的执行顺序变化。
Go调度器是抢占式的，但它也会尽量公平地调度goroutine。在两个goroutine几乎同时准备好发送消息时，Go运行时可能会以某种一致的顺序（例如，根据goroutine的创建顺序或内部ID）进行调度。如果随机延迟的差异不足以打破这种初始的“平衡”，我们就会持续看到交替的输出。
解决方案：延长观察时间
要观察到真正的异步和非同步行为，我们需要给予随机延迟足够的时间来累积差异，并影响goroutine的调度顺序。最直接的方法就是增加main函数中从fanIn channel读取消息的次数。
将main函数中的循环次数从10增加到20或更多，通常就能明显地看到非同步行为：
func main() {
c := fanIn(boring("Joe"), boring("Ann"))
// 延长循环次数，以便观察到异步行为
for i := 0; i < 20; i++ { // 增加到20次通常足以观察到非同步
fmt.Println(<-c)
}
fmt.Printf("You're both boring, I'm leaving...\n")
}修改后的代码运行后，输出可能会变为：
Joe 0 Ann 0 Joe 1 Ann 1 Joe 2 Ann 2 Joe 3 Ann 3 Joe 4 Ann 4 Joe 5 Ann 5 Joe 6 Ann 6 Ann 7 // Ann 抢先了 Joe 7 Joe 8 Joe 9 Ann 8 Ann 9
从上述输出可以看出，在第7次消息发送时，“Ann”的消息先于“Joe”发出，随后在第8、9次消息时，“Joe”又连续发出了两条消息，打破了严格的交替模式。这正是我们所期望的异步行为。
关键注意事项与总结
- 随机性与观察窗口：随机延迟的引入是为了模拟真实世界的非确定性，但其效果需要足够的观察时间才能显现。在并发编程中，短时间的观察可能无法完全揭示系统的动态行为。
- Go调度器的行为：Go调度器是复杂的，它会尽量公平地调度goroutine。在没有显著外部差异（如I/O阻塞或长时间计算）时，goroutine可能会以一种看似有序的方式执行。随机延迟就是引入这种外部差异的一种方式。
- 并发与并行：此示例展示的是并发（concurrent）而非严格的并行（parallel）。即使在单核CPU上，Go运行时也能通过快速切换goroutine来模拟同时执行的效果。随机延迟进一步增强了这种非确定性。
- fanIn模式的健壮性：fanIn模式本身是可靠的，它能有效地将多个数据流汇聚到一个单一的消费者。本例中的“问题”并非模式本身的缺陷，而是对并发系统行为的理解和观察方式。
通过这个例子，我们深入理解了Go语言中fanIn模式下goroutine的异步特性。关键在于，并发行为的非确定性往往需要足够长的观察时间才能充分展现。在调试或验证并发程序时，务必考虑观察窗口对结果判读的影响。
