并发设计模式与陷阱总结
需要预先了解：
1. 并发设计模式与陷阱总结
前四篇讲了 goroutine、channel、同步原语和 context 的用法，这一篇把它们组织成可复用的模式，并把并发编程里最容易踩的坑集中列出来。
1.1 pipeline
**pipeline（流水线）**把任务拆成若干阶段，每个阶段的输入输出都是 channel，数据像流水一样流过：
// 生成器：产生数据
func gen(nums ...int) <-chan int {
out := make(chan int)
go func() {
defer close(out)
for _, n := range nums {
out <- n
}
}()
return out
}
// 阶段：处理数据
func square(in <-chan int) <-chan int {
out := make(chan int)
go func() {
defer close(out)
for n := range in {
out <- n * n
}
}()
return out
}for v := range square(gen(1, 2, 3, 4)) {
fmt.Print(v, " ")
}1 4 9 16每个阶段都是一个独立 goroutine，谁生产谁关闭（defer close(out)），下游用 for range 读到 channel 关闭后自然退出。整条管道就实现了"优雅关闭"。
需要注意：如果下游提前退出（比如 break），上游的 goroutine 会阻塞在发送上，造成泄漏。解决办法是给每个阶段传 ctx，在 select 里同时等待取消：
func square(ctx context.Context, in <-chan int) <-chan int {
out := make(chan int)
go func() {
defer close(out)
for n := range in {
select {
case out <- n * n:
case <-ctx.Done():
return
}
}
}()
return out
}1.2 fan-in / fan-out
fan-out：多个 goroutine 从同一个 channel 读取，把工作分摊开。
fan-in：把多个 channel 的输出合并到一个 channel。
func merge(chs ...<-chan int) <-chan int {
var wg sync.WaitGroup
out := make(chan int)
for _, ch := range chs {
wg.Add(1)
go func(c <-chan int) {
defer wg.Done()
for v := range c {
out <- v
}
}(ch)
}
go func() {
wg.Wait()
close(out) // 所有输入都转发完才关闭输出
}()
return out
}in := gen(1, 2, 3, 4, 5, 6)
c1 := square(in)
c2 := square(in)
c3 := square(in)
for v := range merge(c1, c2, c3) {
fmt.Print(v, " ")
}4 9 1 16 25 36merge 的关键是"用 WaitGroup 等所有转发 goroutine 结束后再关闭输出 channel"——关闭的责任落在唯一的那个 goroutine 上。
1.3 worker pool
固定数量的 worker 消费一个任务队列，是控制并发度最常用的模式：
jobs := make(chan int, 20)
results := make(chan int, 20)
var wg sync.WaitGroup
for w := 1; w <= 3; w++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
for j := range jobs {
time.Sleep(10 * time.Millisecond)
results <- j * 2
}
}(w)
}
go func() {
for i := 1; i <= 6; i++ {
jobs <- i
}
close(jobs) // 任务发完就关闭，worker 的 range 会退出
}()
go func() {
wg.Wait()
close(results) // 所有 worker 结束后关闭结果 channel
}()
total := 0
for r := range results {
total += r
}
fmt.Println("worker pool 结果总和:", total)worker pool 结果总和: 42三个要点：
close(jobs)由生产任务的 goroutine 负责；close(results)必须等所有 worker 退出后再执行，否则会 panic 或丢结果；- worker 数量固定，内存和并发度都可控。
1.4 信号量限流
用带缓冲 channel 实现"最多同时 N 个任务"：
sem := make(chan struct{}, 3)
for i := 1; i <= 6; i++ {
go func(id int) {
sem <- struct{}{} // 获取令牌
defer func() { <-sem }() // 归还令牌
time.Sleep(20 * time.Millisecond)
fmt.Println("任务", id, "完成")
}(i)
}缓冲容量就是并发上限。比 worker pool 更灵活的地方在于：任务本身是按需创建的，只是"同时运行的"被限制住。
1.5 errgroup
golang.org/x/sync/errgroup 把 WaitGroup、错误收集和 context 取消组合在一起：
g, ctx := errgroup.WithContext(context.Background())
g.Go(func() error { /* ... */ })
g.Go(func() error { /* ... */ })
if err := g.Wait(); err != nil {
// 任意一个任务返回非 nil 错误就会拿到
}它的行为：
Wait返回第一个非 nil 错误；- 任意任务出错时，派生的
ctx被取消； - 但取消不会强制停止其他 goroutine，它们必须自己检查
ctx.Done()。
看两种写法的差别：
g2, _ := errgroup.WithContext(context.Background())
g2.Go(func() error {
time.Sleep(20 * time.Millisecond)
return errors.New("模拟失败")
})
g2.Go(func() error {
time.Sleep(100 * time.Millisecond)
fmt.Println("不检查 ctx 的任务会继续跑完")
return nil
})
fmt.Println("g2.Wait:", g2.Wait())不检查 ctx 的任务会继续跑完
g2.Wait: 模拟失败第二个任务没有检查 ctx，所以照样跑完。写成主动响应取消的版本：
g3, ctx3 := errgroup.WithContext(context.Background())
g3.Go(func() error {
time.Sleep(20 * time.Millisecond)
return errors.New("先失败")
})
g3.Go(func() error {
select {
case <-ctx3.Done():
fmt.Println("第二个任务收到取消信号:", ctx3.Err())
return ctx3.Err()
case <-time.After(200 * time.Millisecond):
fmt.Println("不会走到这里")
return nil
}
})
fmt.Println("g3.Wait:", g3.Wait())第二个任务收到取消信号: context canceled
g3.Wait: 先失败SetLimit(n) 可以限制并发数（x/sync v0.3.0+，需要 Go 1.20+）：
g4 := &errgroup.Group{}
g4.SetLimit(2)1.6 定时任务与 ticker
time.NewTicker 按固定间隔触发，必须显式 Stop：
ticker := time.NewTicker(30 * time.Millisecond)
defer ticker.Stop()
for i := 0; i < 3; i++ {
<-ticker.C
fmt.Println("tick", i+1)
}tick 1
tick 2
tick 3几个注意点：
- 不要用
time.Tick，它返回的 ticker 无法停止，会一直占用资源； ticker.C的缓冲只有 1，如果处理速度跟不上，会丢弃中间的 tick，而不是排队；- 需要"每次执行完再等间隔"而不是"固定频率"时，用
time.After或time.Sleep重新计时； - Go 1.23 起，未被引用的
Timer/Ticker可以被 GC 回收，但显式Stop仍然是好习惯。
1.7 goroutine 泄漏排查
泄漏的本质是：goroutine 永远等不到它要等的事件。
func leakyPipeline() <-chan int {
out := make(chan int)
go func() {
defer close(out)
for i := 0; i < 3; i++ {
out <- i
}
}()
return out
}for i := 0; i < 3; i++ {
ch := leakyPipeline()
fmt.Println("读到:", <-ch)
// ch 被丢弃，发送方还阻塞在第二个值上
}初始: 1
读到: 0
读到: 0
读到: 0
泄漏后: 4只读一个值就不读了，发送方永远阻塞在 out <- i 上。三次调用泄漏了三个 goroutine。
排查手段：
runtime.NumGoroutine()观察数量是否只增不减；- pprof 的 goroutine profile：
http://localhost:6060/debug/pprof/goroutine?debug=1能看到每个 goroutine 的调用栈，直接定位卡在哪一行（详见 性能分析与调优）； - 给所有可能阻塞的操作加上
ctx或超时，让 goroutine 有退出路径。
常见泄漏原因：
- 忘记读结果 channel；
- 向无人接收的 channel 发送；
time.Ticker没有Stop；- 阻塞在锁上（锁的持有者已退出或死锁）；
- 请求取消后仍阻塞在 IO 上。
1.8 陷阱总结表
| 陷阱 | 现象 | 规避方式 |
|---|---|---|
| 闭包捕获循环变量（1.22 之前） | 所有闭包看到循环结束时的值 | 把循环变量作为参数传入，或用 i := i 复制；1.22+ 默认每轮独立变量 |
WaitGroup.Add 放在 goroutine 内 |
Wait 提前返回，任务没跑完 |
在 go 语句之前调用 Add；1.25+ 可用 wg.Go |
拷贝含 Mutex 的结构体 |
锁失效，保护不住数据 | 用指针接收者/指针传参；go vet 会报 “passes lock by value” |
| map 并发读写 | fatal error: concurrent map writes，不可 recover |
用 sync.Mutex 或 sync.Map |
| nil channel 收发 | 永久阻塞，最终 all goroutines are asleep - deadlock! |
用 select + default，或在 select 中作为禁用分支 |
| 无缓冲 channel 自收自发 | 同一 goroutine 里死锁 | 发送和接收放在不同的 goroutine |
| channel 元素是大结构体 | 每次收发都完整拷贝，GC 压力大 | 传指针（并保证不再并发访问）或改小结构体 |
| 循环变量在 goroutine 中使用 | 所有 goroutine 可能拿到同一个值（1.22 之前） | 同上，1.22+ 已修复 |
忘记 cancel() |
context 树无法释放，定时器泄漏 | defer cancel() 紧跟派生语句之后 |
注意：Go 1.22 起，
for循环的循环变量每轮迭代都是新变量，go func() { fmt.Println(i) }()不再需要i := i。但闭包捕获的是变量本身这条规则没有变，显式共享变量的场景仍然要小心。
1.9 机制选型速查表
| 需求 | 机制 |
|---|---|
| 接收任务结果 | channel（或函数返回值） |
| 完成通知/等待一批任务 | sync.WaitGroup、done channel |
| 传递数据/所有权 | channel |
| 保护共享状态 | sync.Mutex / sync.RWMutex |
| 单个变量计数/标志 | sync/atomic（含 1.19+ 类型化 API） |
| 限制并发数 | 带缓冲 channel（信号量）、errgroup.SetLimit |
| 取消 / 超时 | context（详见 context） |
| 只执行一次 | sync.Once |
| 复用临时对象 | sync.Pool |
| 定时/周期任务 | time.NewTicker + Stop |
选型时先问自己三个问题：
- 数据是传递还是共享？传递用 channel，共享用锁/原子操作。
- 是一次性的结果还是持续的事件流？一次性用
WaitGroup/返回值，事件流用 channel。 - 有没有取消/超时需求？有就带
ctx。
1.10 练习
- 用 pipeline +
errgroup实现一个"读取一批文件、并发统计行数、汇总结果"的程序，要求任一文件出错时全部取消。 - 用信号量限制并发数为 4，抓取 20 个 URL（用
http.Get或time.Sleep模拟），统计总耗时。 - 写一个必然泄漏的 goroutine，用
runtime.NumGoroutine()确认泄漏，再改成带ctx的版本验证不再泄漏。
相关推荐
2026-09-09
sync 包与原子操作
需要预先了解： goroutine 与并发初探 channel sync 包与原子操作 多个 goroutine 同时读写同一份数据，如果不加保护，就会产生竞态条件（race condition）。这一篇讲清楚竞态是怎么发生的、怎么用 -race 检测它，以及 sync.Mutex、sync.RWMutex、sync/atomic、sync.Map、sync.Pool 各自的适用场景。 竞态条件 var counter int func main() { var wg sync.WaitGroup for i := 0; i < 1000; i++ { wg.Add(1) go func() { defer wg.Done() counter++ }() } wg.Wait() fmt.Println("counter =", counter) } 期望值是 1000，实际运行可能得到： counter = 968 原因在于 counter++ ...
2026-09-09
context
需要预先了解： channel sync 包与原子操作 context 一个请求往往要派生多个 goroutine：查数据库、调下游服务、写日志。如果其中一步超时或客户端断开，其他步骤需要尽快停下。context 就是用来统一传递取消信号、截止时间和请求范围内的元数据的标准机制。 需求引入 假设一个函数要并发做三件事，任何一件失败或超时就整体放弃。如果每个 goroutine 各自用 done channel，代码会变成一堆手写的通知逻辑： done1 := make(chan struct{}) done2 := make(chan struct{}) // 谁来关闭？超时怎么办？取消要不要级联？ context 把这些问题标准化：它是一棵可级联取消的树，父节点取消时所有子节点都会收到通知。 Context 接口 type Context interface { Deadline() (deadline time.Time, ok bool) Done() <-chan struct{...
2026-09-09
channel
需要预先了解： goroutine 与并发初探 channel channel 是 goroutine 之间传递数据的管道，也是 Go 并发模型的核心。它同时承担两件事：传递数据和同步。这一篇讲清楚无缓冲与有缓冲的差别、close 的规则、select 的多路复用，以及几个会让程序直接崩溃的操作。 设计哲学 Go 的并发信条是： 不要通过共享内存来通信，而要通过通信来共享内存。 意思是：与其让多个 goroutine 抢着读写同一块内存（然后用锁保护），不如让数据在 goroutine 之间传过来，同一时刻只有一方持有它。channel 就是传递的载体。 无缓冲 channel：同步语义 make(chan T) 创建的是无缓冲 channel。它的发送和接收必须同时就位才能完成——发送方会一直阻塞，直到有接收方来取： ch := make(chan int) go func() { fmt.Println("发送前") ch <- 1 fmt.Println("发送完成") }() time.Sleep(100 * ti...
2026-09-09
goroutine 与并发初探
需要预先了解： 函数 包与模块：代码组织 goroutine 与并发初探 Go 的并发能力从语言层面就开始了：一个 go 关键字就能启动一个 goroutine。这篇先讲清楚"并发"与"并行"的区别、goroutine 的启动与开销，再引出 sync.WaitGroup、sync.Once 这两个基础同步工具，最后给出 GMP 调度模型的概览，为后面几篇铺路。 并发与并行 先区分两个概念： 并发（concurrency）：多个任务在重叠的时间段内推进，宏观上"同时"发生，微观上可能是交替执行； 并行（parallelism）：多个任务在同一个时刻真正同时执行，需要多核支持。 并发是一种程序结构，并行是一种执行状态。一个程序可以并发但不并行（比如只给一个 CPU 核心）。 几个系统层面的执行单元： 概念 说明 进程 拥有独立地址空间的执行单元，进程之间默认不共享内存 线程 进程内的执行单元，共享进程的地址空间，由操作系统调度 协程 用户态的轻量执行单元，由语言运行时或库调度...
2026-09-09
泛型
需要预先了解： 接口 包与模块：代码组织 泛型 Go 1.18 引入了泛型（generics）：函数和类型可以带类型参数，在调用或使用时才确定具体类型。它解决的是"同一套逻辑要写很多遍，只有类型不同"的问题——比复制粘贴好维护，比 any + 类型断言更安全，也比接口更直接（不需要为每种类型实现方法）。 从重复代码出发 先看一个没有泛型的场景：为 int 和 float64 各写一遍求最小值的函数。 func MinInt(a, b int) int { if a < b { return a } return b } func MinFloat(a, b float64) float64 { if a < b { return a } return b } 两个函数除了类型以外完全相同。用泛型可以合成一个： func Min[T Ordered](a, b T) T { if a < b { ...
2026-09-09
测试
需要预先了解： 包与模块：代码组织 channel 标准库（二）：JSON 与 HTTP 服务 测试 Go 把测试做成了语言工具链的一部分：_test.go 文件、go test 命令、testing 包，不需要额外框架。这一篇讲单元测试、表驱动测试、基准测试、模糊测试、示例测试和 HTTP 测试的写法，以及覆盖率怎么读。 测试文件的组织 测试代码放在以 _test.go 结尾的文件里，和被测试代码同一个目录： calc/ ├── calc.go // package calc ├── calc_test.go // package calc（同包测试） └── calc_ext_test.go // package calc_test（外部测试包） 两种包名的区别： 写法 能访问 适合 package calc 包内所有标识符（含未导出的） 测试内部实现 package calc_test 只有导出的标识符 测试对外 API，避免依赖...
