Go语言并发模型全解析

本篇文章向大家介绍《Go语言并发模型设计详解》，主要包括，具有一定的参考价值，需要的朋友可以参考一下。

Go并发需谨慎控制goroutine数量，避免盲目启动；须用WaitGroup、带缓冲channel或errgroup.Group节流；HTTP请求天然限流可单启goroutine，批量处理需worker pool；time.AfterFunc等需context控制生命周期；channel操作不当易导致阻塞或panic。

Go 里并发不是靠加 goroutine 就完事

盲目在循环里起 go func() 是最常见错误。goroutine 轻量，但不免费：调度开销、内存占用、竞态风险都会随数量线性增长。真实系统里，必须配合控制手段——要么用 sync.WaitGroup 等待结果，要么用带缓冲的 chan 做节流，要么直接上 errgroup.Group。

• HTTP 服务中每个请求启一个 goroutine 是安全的，因为请求天然限流（连接数、超时、反向代理限制）
• 批量处理 10 万条日志？不能直接 for _, log := range logs { go process(log) }，得用 worker pool 模式
• time.AfterFunc 或 time.Tick 启的 goroutine 容易泄漏，务必配 context.WithCancel 控制生命周期

channel 用法错一半，程序就卡死或 panic

channel 不是万能队列，它的阻塞行为直接决定 goroutine 是否挂住。写入已关闭的 channel 会 panic；从已关闭且无数据的 channel 读，得到零值；无缓冲 channel 写之前没人读，就永远阻塞。

• 发送前先检查 select { case ch 避免阻塞
• 关闭 channel 的责任必须明确——通常只由发送方关闭，接收方不应 close
• 用 for range ch 读 channel 时，如果 sender 永不 close，循环永不退出
• 不要用 channel 传大结构体，避免拷贝；优先传指针或 sync.Pool 复用对象

func worker(id int, jobs <h3>context.Context 不只是传取消信号</h3><p>它还承载超时、截止时间、值传递、取消链路。漏传 <code>ctx</code> 到下游调用（比如 <code>http.Client.Do(ctx, req)</code>、<code>db.QueryContext(ctx, ...)</code>），整个链路就失去控制能力。</p>

• HTTP handler 入口的 ctx 来自 r.Context()，别自己 new
• 用 context.WithTimeout 时，记得 defer cancel()，否则可能泄露 timer
• context.WithValue 只适合传请求范围的元数据（如用户 ID、trace ID），禁止传业务参数或函数对象
• 数据库连接池、gRPC client、Redis client 都要求传 ctx，否则超时和取消无效

sync.Mutex 和 atomic.Value 不是二选一

简单字段读写用 atomic.LoadInt64 / atomic.StoreUint64 更快；但涉及多个字段关联更新（比如状态 + 时间戳）、或需要条件等待（sync.Cond），就必须用 sync.Mutex。混用两者极易出错。

• atomic.Value 只能存指针或接口类型，且每次 Store 都是全量替换，不适合高频小字段更新
• 用 sync.RWMutex 时，注意 RUnlock 必须和 Rlock 成对，漏掉会导致后续所有写锁永久阻塞
• struct 字段加 mu sync.RWMutex 后，别忘了所有访问都得显式加锁——编译器不会报错，但数据竞争检测器（go run -race）会抓到

真正难的不是写并发代码，而是判断某段逻辑是否必须并发、并发粒度该划多细、失败后怎么回滚或重试。这些没法靠语法糖解决，得结合监控指标（goroutine 数、channel 阻塞数、GC pause）和压测反复验证。

本篇关于《Go语言并发模型全解析》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！