用 sync.WaitGroup 等待 goroutine 完成:Add(1) 必须在 go 前调用,Done() 推荐 defer 调用;需多个 goroutine 但只取首个结果时,用 select 监听同类型 channel 实现“first result wins”。
用 sync.WaitGroup 最直接。它不传数据,只管“有几个 goroutine 在跑、它们是否都结束了”。WaitGroup 的 Add 必须在 goroutine 启动前调用,否则可能 Wait 永远阻塞或 panic。
Add(1) 要在 go func() {...}() 之前,不能写在 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() // 主协程在这里阻塞,直到上面的 gorouti
ne 调用 Done用 select + chan 配合 default 或 context.WithCancel 控制超时,但更常见的是用 select 监听多个 chan,谁先发就收谁——这就是 “first result wins” 模式。
chan int
context.Context 通知取消ch1 := make(chan string, 1)
ch2 := make(chan string, 1)
go func() { ch1 <- "from A" }()
go func() { ch2 <- "from B" }()
select {
case s := <-ch1:
fmt.Println(s)
case s := <-ch2:
fmt.Println(s)
}
用无缓冲 channel(make(chan struct{}))做“信号量”最轻量。它不传业务数据,只起同步作用,零内存开销,语义清晰。
ch ,接收方用 阻塞等待
defer 确保发送一定发生int 或 bool 类型 channel 传信号——容易误读意图,也浪费空间ready := make(chan struct{})
go func() {
time.Sleep(50 * time.Millisecond)
close(ready) // 或用 ready <- struct{}{}
}()
<-ready // 主协程在此阻塞,直到另一端发出信号
fmt.Println("now start")能读,但行为分两种:带 ok 判断的接收会返回零值 + false;不带判断的接收也会返回零值,但无法区分是“刚关闭”还是“还没写入”。这是最容易踩的坑。
send on closed channel
for range ch 自动处理关闭逻辑,比手动 更安全
ch := make(chan int, 2) ch <- 1 ch <- 2 close(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 关闭状态的误判,往往出现在没有统一读取约定的多人协作代码里。