Go中goroutine启动后不阻塞主函数,主函数退出则所有goroutine强制终止;需用sync.WaitGroup等待或time.Sleep临时观察,且循环中传参避免闭包陷阱;channel使用不当易致泄漏或死锁。
动后不等待,主函数退出就结束Go 的 goroutine 是轻量级线程,但启动后默认不阻塞主流程。如果主函数执行完直接退出,所有未完成的 goroutine 会被强制终止,看不到输出。
time.Sleep() 临时观察效果(仅测试用,不可用于生产)sync.WaitGroup 等待所有任务完成goroutine 并传入循环变量——容易捕获到变量最终值,需显式传参或用局部变量捕获package mainimport ( "fmt" "sync" "time" )
func main() { var wg sync.WaitGroup
for i := 0; i < 3; i++ { wg.Add(1) go func(id int) { defer wg.Done() fmt.Printf("goroutine %d running\n", id) time.Sleep(time.Second) }(i) // 注意:这里把 i 作为参数传入,避免闭包陷阱 } wg.Wait() // 主 goroutine 阻塞等待全部完成 fmt.Println("all done")}
goroutine 泄漏:忘记关闭 channel 或未消费完数据
当用
channel配合goroutine做生产者-消费者模型时,若发送端关闭了channel,但接收端没处理完或没检测关闭状态,可能造成接收goroutine永久阻塞;反之,若接收端已退出而发送端还在往无缓冲 channel 写,也会死锁。
for range ch 自动处理 channel 关闭select + time.After(),避免无限等待go func(ch chan int) {
for i := 0; i < 5; i++ {
select {
case ch <- i:
case <-time.After(time.Second):
fmt.Println("send timeout, skip")
}
}
close(ch)
}(ch)每个 goroutine 初始栈约 2KB,虽轻量,但百万级并发仍会耗尽内存;同时 Go 调度器不是为“越多越好”设计的,过度创建反而降低吞吐。
立即学习“go语言免费学习笔记(深入)”;
runtime.GOMAXPROCS(n) 控制并行数(通常保持默认即可)runtime.NumGoroutine() 监控当前数量,排查泄漏每个 goroutine 独立运行,其中的 panic 默认只终止自身,不会中断主流程,也容易被忽略。
recover() 在 goroutine 内部捕获 panic(必须在 defer 中调用)go func(id int) {
defer func() {
if r := recover(); r != nil {
fmt.Printf("goroutine %d panicked: %v\n", id, r)
}
}()
panic("something went wrong")
}(1)实际写并发逻辑时,最常被忽略的是「等待机制」和「错误隔离」——前者导致程序提前退出、结果丢失,后者导致 panic 静默失败、问题难以复现。