Golang协程依赖管理技巧解析

本文深入讲解了 Go 语言中 goroutine 依赖处理的两大核心技巧：一是使用 sync.WaitGroup 安全、可靠地等待多个协程完成，强调 Add 必须在 goroutine 启动前调用、Done 推荐搭配 defer 防遗漏，避免死锁或 panic；二是通过 select 监听多个同类型 channel 实现“首个结果胜出”（first result wins）模式，兼顾响应速度与资源效率，并提醒注意未被选中 channel 的清理及协程及时退出问题——这些实战要点能帮你写出更健壮、高效的并发代码。

goroutine 启动后怎么等它做完再继续？

用 sync.WaitGroup 最直接。它不传数据，只管“有几个 goroutine 在跑、它们是否都结束了”。WaitGroup 的 Add 必须在 goroutine 启动前调用，否则可能 Wait 永远阻塞或 panic。

• Add(1) 要在 go func() {...}() 之前，不能写在 goroutine 内部
• 每个 goroutine 结束前必须调用 Done()，推荐用 defer wg.Done() 防遗漏
• 不要重复 Add 同一个 WaitGroup 多次却不 Done，会卡死

var wg sync.WaitGroup
wg.Add(1)
go func() {
    defer wg.Done()
    time.Sleep(100 * time.Millisecond)
    fmt.Println("done")
}()
wg.Wait() // 主协程在这里阻塞，直到上面的 goroutine 调用 Done

需要等多个 goroutine，但只关心“第一个返回的结果”？

用 select + chan 配合 default 或 context.WithCancel 控制超时，但更常见的是用 select 监听多个 chan，谁先发就收谁——这就是 “first result wins” 模式。

• 所有结果 channel 必须是同类型，比如 chan int
• 避免漏收：没被选中的 channel 会一直挂着，如果后续还要读，得确保有 goroutine 在持续写或关闭它
• 如果只想要第一个，其余 goroutine 应该能及时退出，否则浪费资源；可用 context.Context 通知取消

ch1 := make(chan string, 1)
ch2 := make(chan string, 1)
go func() { ch1 select {
case s := <-ch1:
fmt.Println(s)
case s := <-ch2:
fmt.Println(s)
}

goroutine A 必须等 goroutine B 发出信号才能开始？

用无缓冲 channel（make(chan struct{})）做“信号量”最轻量。它不传业务数据，只起同步作用，零内存开销，语义清晰。

• 发送方用 ch ，接收方用 <-ch 阻塞等待
• 无缓冲 channel 的 send 和 receive 必须配对，否则会死锁；建议用 defer 确保发送一定发生
• 别用 int 或 bool 类型 channel 传信号——容易误读意图，也浪费空间

ready := make(chan struct{})
go func() {
    time.Sleep(50 * time.Millisecond)
    close(ready) // 或用 ready <h3>channel 关闭后还能读吗？读完会怎样？</h3><p>能读，但行为分两种：带 <code>ok</code> 判断的接收会返回零值 + <code>false</code>；不带判断的接收也会返回零值，但无法区分是“刚关闭”还是“还没写入”。这是最容易踩的坑。</p>

• 关闭 channel 前确保没人再往里写，否则 panic：send on closed channel
• 多个 goroutine 从同一 channel 读没问题，但关闭只能由写方决定，且只能关一次
• 用 for range ch 自动处理关闭逻辑，比手动 <-ch 更安全

ch := make(chan int, 2)
ch v, ok := <-ch // v==1, ok==true
v, ok = <-ch  // v==2, ok==true
v, ok = <-ch  // v==0, ok==false ← 注意：v 是 int 零值，不是错误

实际依赖控制中，WaitGroup 和 chan struct{} 解决“是否完成”，select 解决“谁先完成”，而 channel 关闭状态的误判，往往出现在没有统一读取约定的多人协作代码里。

今天关于《Golang协程依赖管理技巧解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！