Go 并发编程实战:goroutine 与 channel

并发是 Go 的一等公民。很多团队选 Go,第一理由不是语法简洁,而是"天生适合写高并发后端"。但"goroutine + channel"看起来简单,工程上踩坑的人却比比皆是——泄漏、死锁、竞态,每一种都能让你在凌晨三点定位线上问题。

这篇文章不讲官网教程能查到的东西,只讲实战:每个机制背后的取舍、每个模式适用的场景、每个陷阱长什么样、怎么防。

一、Go 并发的哲学:不要用共享内存通信

绝大多数语言教你的并发模型是:起一堆线程,共享一块内存,然后用锁保护它。这套模型没有错,但它有一个根本问题——共享内存 + 锁让程序的状态变得难以推理。你锁住了,我才能读;谁忘了锁、谁锁的粒度不对、谁嵌套了锁,都会引发难以复现的 bug。

Go 选择了另一条路,源自 Hoare 在 1978 年提出的 CSP(Communicating Sequential Processes)模型。Go 官方那句口号翻译过来就是:

不要用共享内存来通信,而要用通信来共享内存。

意思是:与其让多个 goroutine 抢同一块变量、靠锁维持秩序,不如让每个 goroutine 拥有自己那份状态,通过 channel 把数据"递"给对方。数据的所有权在 channel 上一目了然——谁在接收,谁就拥有它,不需要锁。

这不是教条。共享内存和锁该用的时候 Go 也支持(sync.Mutex),但在设计阶段,优先想"数据该怎么流动",而不是"该怎么上锁"。这个思维转变,是从"写 Java/Python 的并发"切换到"写 Go 的并发"的分水岭。

二、goroutine:几 KB 的轻量级线程

启动一个 goroutine 就是 go f():

go processRequest(req)
go func(url string) {
    fetch(url)
}(u)

goroutine 不是 OS 线程。它由 Go runtime 调度,初始栈只有 2KB 左右,按需增长。一台普通服务器轻松能起几十万个 goroutine,而 OS 线程起几千个就吃力了。这种轻量是 Go 并发的物质基础。

背后是 GMP 调度模型:

• G(Goroutine):你写的协程。
• M(Machine):OS 线程,真正执行代码的载体。
• P(Processor):逻辑处理器,持有可运行的 G 队列。P 的数量由 GOMAXPROCS 决定,默认等于 CPU 核数。

一个 M 绑一个 P,从 P 的本地队列拿 G 来跑。当某个 G 发生系统调用阻塞,M 会和 P 解绑,让另一个 M 接走 P 继续跑别的 G——这就是 Go 为什么在密集 IO 下也能撑住高并发:阻塞不浪费线程。

理解 GMP 的实战意义在于:goroutine 之间的切换是用户态的,极廉价,所以"为每个请求起一个 goroutine"是 Go 后端的标准姿势,不必心疼。

三、channel:同步与通信的基石

channel 是 goroutine 之间传递数据的管道:

ch := make(chan int)    // 无缓冲
ch2 := make(chan int, 5) // 有缓冲,容量 5

无缓冲 channel 是同步的:发送方发送后必须等接收方接收,否则阻塞;反之亦然。它本质是一次"握手"——发送和接收严格配对。常用于两个 goroutine 之间的同步点。

done := make(chan struct{})
go func() {
    doWork()
    close(done) // 通知主 goroutine
}()
<-done // 阻塞,直到 done 被关闭

有缓冲 channel 是异步的:缓冲区没满之前,发送不阻塞;满了才阻塞;缓冲区空时接收阻塞。它解耦了生产者和消费者的节奏。

阻塞语义要记牢:向已关闭的 channel 发送会 panic;从已关闭的 channel 接收会得到零值且不阻塞。close 永远只应由"发送方"调用,且一个 channel 只能 close 一次——这是 channel 的基本纪律。

四、select:多路复用的艺术

select 让一个 goroutine 同时等待多个 channel,谁先就绪就执行谁:

select {
case msg := <-msgs:
    handle(msg)
case <-time.After(3 * time.Second):
    return // 超时退出
default:
    // 没有任何 channel 就绪,非阻塞走这里
}

两个高频用法:超时控制(time.After / context)和非阻塞操作(default 分支)。生产代码里几乎所有"等待 channel"的地方都该配一个超时或取消信号,否则 goroutine 可能永远卡死。

select 的分支选择是随机的(多个就绪时),这个特性在负载均衡场景很有用。

五、并发模式:四种工程上反复出现的套路

Worker Pool(任务池)

固定数量的 worker 从 job channel 取任务执行,结果写回 result channel。核心价值是控制并发度——防止一次性起十万 goroutine 把下游打挂。

func worker(id int, jobs <-chan int, results chan<- int) {
    for j := range jobs {
        results <- j * j
    }
}

func main() {
    jobs := make(chan int, 100)
    results := make(chan int, 100)
    for w := 1; w <= 3; w++ { // 3 个 worker
        go worker(w, jobs, results)
    }
    for i := 1; i <= 50; i++ { jobs <- i }
    close(jobs)
}

Fan-out / Fan-in(扇出扇入)

把一个任务拆给多个 goroutine 并行处理(fan-out),再把结果汇总到一个 channel(fan-in)。适合 CPU 密集且可拆分的任务,比如多副本并行查多个数据源再合并。

Pipeline(流水线)

每个阶段是一组 goroutine,通过 channel 串联。上游的输出是下游的输入。像 Unix 管道:读取 → 解析 → 过滤 → 聚合。每个 stage 独立伸缩,清晰且易测试。

Done channel(取消信号)

done := make(chan struct{})
go func() {
    for {
        select {
        case <-done:
            return // 收到取消,优雅退出
        case x := <-input:
            process(x)
        }
    }
}()
close(done) // 通知所有监听者退出

工程中更推荐用 context.Context——它能让取消信号在调用链上自动传播,比裸 done channel 更可维护。

六、sync 包:channel 解决不了的场景

不是所有并发问题都适合用 channel。sync 包提供经典原语:

• WaitGroup:等一组 goroutine 全部结束。批量任务必备。

  var wg sync.WaitGroup
  for _, url := range urls {
      wg.Add(1)
      go func(u string) {
          defer wg.Done()
          fetch(u)
      }(url)
  }
  wg.Wait()
  

• Mutex / RWMutex:互斥锁 / 读写锁。保护一个被并发访问的 map、计数器,比 channel 直接。RWMutex 适合读多写少。
• Once:保证某段初始化代码全局只执行一次,单例、配置加载的标准做法。

实战经验:保护"状态"用 Mutex,传递"数据"用 channel。两者搭配使用才是常态。

七、陷阱:泄漏、死锁、竞态

Goroutine 泄漏

goroutine 启动后永远阻塞、无法退出,GC 也回收不了它引用的内存。最典型:向一个无人接收的 channel 发送、或等待一个永不关闭的 done。

// 泄漏:ch 满了,发送方永远阻塞
func leak() {
    ch := make(chan int, 1)
    ch <- 1
    go func() { ch <- 2 }() // 没人接收,泄漏
}

防法:每个 goroutine 都要有明确的退出路径,通过 context 或 done channel 控制。线上排查可用 pprof 的 goroutine profile。

死锁

所有 goroutine 互相等待,程序整个卡住。常见于:无缓冲 channel 只有发送没有接收、锁嵌套顺序不一致。Go runtime 能检测"全死锁"并 panic,但部分死锁(某个 goroutine 卡死)检测不到,得靠超时和设计规避。

竞态(Race Condition)

多个 goroutine 并发读写同一变量且至少一个是写,没有同步。结果是输出随调度顺序变化,极难复现。Go 自带 race detector,跑测试时加 -race:

go test -race ./...
go run -race main.go

线上 CI 必跑 race 检测,能挡掉绝大多数并发 bug。

context 取消传播

context.WithCancel / WithTimeout 生成的 ctx,要在每个 goroutine 里 select { case <-ctx.Done(): return }。否则父调用取消了,子 goroutine 还在傻跑,照样泄漏。长任务里务必周期性检查 ctx.Done()。

小结

• 哲学优先:用"通信共享内存"思考,数据所有权交给 channel,减少共享和加锁。
• 轻量不等于免费:goroutine 再轻也得有退出路径,没有"结束机制"的 goroutine 就是潜在泄漏。
• channel 三件事:无缓冲=同步握手,有缓冲=解耦队列,close 只能由发送方调一次。
• select + context 是生产标配:超时、取消、多路等待,缺一不可。
• race detector 是底线:CI 上 -race 必开,它能在测试阶段就揪出大多数竞态。

并发不是把 go 加到函数前面,而是为每一次"启动"想清楚"如何结束"。写得出退出路径的并发,才叫驾驭了 Go。