Go并发编程实战：从goroutine、channel到GMP模型与性能调优

1. 为什么咱们都该好好学学Go的并发

干咱们这行的，迟早会碰到并发这道坎。Java里有线程池，Python里有GIL，C++里有各种锁和原子操作，轮子不少，但真正想把并发写得又简单又不容易出错，Go绝对是绕不开的那一个。我最早接触Go其实挺功利，就是想找一个写并发不头疼的语言，结果一用就是好几年，越写越觉得它把并发这件事的门槛压到了极低。Go语言里你不需要面对一屏幕的Thread、ExecutorService和Future，一个go关键字就能让函数跑在独立的执行体上，配合channel来做消息传递，整个心智负担小了很多。

如果说得直白一点，Go语言并发编程的核心价值就三条：一是开箱即用的高并发能力，goroutine几十KB的栈空间起步，单机轻松撑起几万甚至几十万的并发任务；二是语言级别的同步原语，channel、select、sync包这些写在语法和标准库里，不用依赖第三方框架；三是调试和排查体验相对友好，race detector、pprof配合起来，能让你在开发阶段就抓住一大批并发bug。

这篇文章我打算按一条从入门到进阶的路线来写，从Goroutine和调度模型讲起，到channel、select、sync包的实操，再到context控制、并发模式、常见坑和性能调优。整个过程中会穿插大量可以照抄的代码片段，也会把我实际踩过的坑和排查思路一并讲清楚。适合刚接触Go并发的新手，也适合那些写过一段时间但总觉得隔着一层纸的朋友。读完一遍之后，你至少能做到：自己写并发程序时知道该选什么机制，同事的代码出问题你能快速定位，压测和调优的时候不至于两眼一抹黑。

在正式开始之前，先把环境准备好。官方下载地址直接拿对应平台的安装包就行，装完之后跑一下go version确认没问题。值得提醒的是，从Go 1.20开始，很多默认行为已经有了变化，比如go命令本身的模块感知构建默认打开，老项目如果还在用GOPATH模式，建议尽早迁移到modules。另外，如果你之前了解过Go的GUI开发，可能会看到Fyne这个库，它跟Go 1.20的兼容性算是比较稳的，不过我建议学习阶段别碰GUI，专心把并发基础打牢，后面想做什么都能顺手很多。

2. Goroutine与GMP调度模型：理解并发的地基

2.1 Go并发哲学：不要通过共享来通信，要通过通信来共享

很多从Java转过来的朋友，一开始都会不自觉地用“共享内存+锁”的思路写Go并发代码。比如搞一个map，多个goroutine去读，再拿一把Mutex去保护写入。这当然能跑，但完全没用到Go的精华。

Go语言创始人Rob Pike有句名言：Do not communicate by sharing memory; instead, share memory by communicating.翻译成大白话就是，别先把数据放在公共变量里，然后让各个协程去抢锁访问；而是让协程之间通过消息传递的方式把数据送过去。channel就是这条消息通道，send方把数据发出去，receive方拿到数据，彼此不需要接触对方的内部状态。

用生活里的场景来类比，就好比厨房里三个厨师做菜。共享内存模式是：大家共用一个大案板，谁要用都得先去抢菜刀和案板的使用权（加锁），用完了再还给公共区域；通信模式则是：每个厨师有自己的备菜区，做完一道菜直接放到传菜口（channel），下一个人从传菜口取走，不需要去动别人的操作台。后者的好处是，数据的所有权跟着消息走，哪一刻该谁处理，一目了然，根本不会出现两个人同时切同一颗菜的问题。

可能有人会问，那Go是不是就不需要锁了？也不是，标准库里的sync.Mutex、atomic包该用还是得用。只不过你要意识到，Go更希望你优先用channel来表达协程间的协作，锁只是兜底方案。这个思想贯穿整篇文章，理解透了，后面看各种并发模式都会顺畅很多。

2.2 GMP模型：为什么goroutine能那么轻

很多人一开始不理解goroutine和线程的区别。Java里每开一个Thread，操作系统就要创建一个线程，线程栈默认1MB左右，创建销毁代价都不小。而Go的goroutine是运行在Go运行时（runtime）层面的“用户态协程”，初始栈极小（Go 1.20里大约2KB），按需增长，几万个goroutine同时跑也完全扛得住。

这里必须要提的就是Go调度器的GMP模型：

• G（Goroutine）：你要执行的那个函数体，包含了栈信息、状态等。创建成本极低。
• M（Machine）：真正干活的线程，和操作系统的线程一一对应，负责从队列里取出G来执行。
• P（Processor）：一个逻辑处理器，默认数量等于GOMAXPROCS（通常就是CPU核心数）。每个P手里有一个本地可运行队列，存着等待执行的G。

Go调度的套路简单说就是：M需要执行G，必须先去绑定一个P，然后从P的本地队列里拿G来跑。如果本地队列空了，就会去全局队列或者其他P的队列里“偷”一些G过来，这也就是常说的work stealing。这套机制让Go能够在多核CPU上尽量把负载打散，实现高吞吐。

从编程角度讲，你不太需要关心M和P具体怎么调度，但理解一个事情非常重要：goroutine不是抢占式的。在Go 1.14之前，如果你在一个goroutine里写了个死循环，它可能把某个M一直占着不撒手，导致其他goroutine无法被调度。Go 1.14之后引入了基于信号的异步抢占机制，超过10ms的goroutine会被强制打断，所以极端场景下系统不会完全卡死，但依然不鼓励你写长循环不主动让出。

2.3 动手写第一个并发程序：go关键字的最简用法

光说不练假把式，咱们先写一个最小可运行的例子：

package main import ( "fmt" "sync" ) func main() { var wg sync.WaitGroup for i := 1; i <= 5; i++ { wg.Add(1) go func(id int) { defer wg.Done() fmt.Printf("goroutine %d 执行中\n", id) }(i) } wg.Wait() fmt.Println("所有 goroutine 执行完毕") }

这段代码里，go func(id int) {...}(i)就是启动一个goroutine，注意参数i是通过函数参数传入的。很多人第一次写容易直接在闭包里捕获循环变量i：

for i := 1; i <= 5; i++ { go func() { fmt.Println(i) // 有坑！ }() }

在Go 1.22之前，这个闭包捕获的是同一个i变量，等goroutine真正运行的时候，i可能已经变成6了，打印出来全是6。Go 1.22开始循环变量每次迭代会创建新变量，这个坑算被官方填了，但如果你还在维护老代码，或者在其它语言里养成了随手引用的习惯，建议还是规规矩矩用传参的方式，一来兼容老版本，二来看起来也清楚。

3. Channel与select：Go并发的主力通信工具

3.1 Channel的三种形态：双向、只发送、只接收

如果说goroutine是Go并发的“执行单元”，channel就是这些执行单元之间的“消息管道”。定义一个channel很简单：

ch := make(chan int) // 无缓冲channel chBuf := make(chan int, 10) // 有缓冲channel

从类型上，channel可以分三种：

• chan int：可读可写，最常用；
• chan<- int：只发送，只能写入，不能读取；
• <-chan int：只接收，只能读取，不能写入。

后两种一般用在函数参数里，用来约束这个函数“只能往channel里发数据”或者“只能从channel里取数据”。这并不意味着这个channel本身无法反向操作，而是在编译期就帮你限制住了，避免了调用方乱来。比如一个生产者函数可以定义成：

func producer(ch chan<- int) { ch <- 42 }

调用方却可以拿一个双向channel传进来。这种设计本身就是一种文档，读代码的时候一眼就能看出来谁是生产者，谁是消费者。

3.2 无缓冲Channel与有缓冲Channel的核心差异

这是新手最容易迷惑的地方，两个概念搞不清楚，后面写出来的代码动不动就死锁。

无缓冲channel：发送和接收必须同时准备好，否则发送方会阻塞住，直到有接收方来取。它天然有“同步”的作用，两端的goroutine会像交接班一样碰头。

ch := make(chan int) go func() { ch <- 1 // 这里会阻塞，直到主goroutine来取 }() value := <-ch // 主goroutine在这里取到了1

有缓冲channel：发送方只有在缓冲区满的时候才会阻塞，接收方只有在缓冲区空的时候才会阻塞。它相当于加了一个中间仓库，发送方把货往仓库一扔就先走了，不一定非得等接收方伸手来接。

ch := make(chan int, 3) ch <- 1 // 不会阻塞，因为缓冲区还有空间 ch <- 2 ch <- 3

有缓冲的channel比较像生活中的邮箱，投递员投进去就走，收件人什么时候取都行，只要邮箱不爆满。无缓冲的channel则像直接面对面交收快递，必须两个人同时在场。

我实际项目里的经验是：优先考虑有缓冲channel，尤其是在生产者速度不稳定的场景下，缓冲能帮你吸收一阵“突发流量”。但这个缓冲大小需要算，不是越大越好。设置得太大，消费者处理不过来，内存里积压的数据越来越多，一旦服务重启，这些数据全丢。设置得太小，生产者会被反复阻塞，吞吐受限。

顺便提一句，很多人会问channel会不会有性能问题。其实在Go里，channel的底层是用带锁的队列实现的，所以它的性能不如纯粹的原子操作或互斥锁访问共享变量。但并发程序里性能不只是看单次操作成本，它还涉及锁粒度、阻塞切换开销、代码清晰度。channel带来的可维护性收益，绝大多数情况下是远超那点微秒级开销的。

3.3 select多路复用：同时等多个channel

绝大多数并发程序不会只跟一个channel打交道。比如一个网络服务，既要等请求入口，又要等退出信号，这时候就需要select了。

func worker(ch <-chan int, quit <-chan struct{}) { for { select { case v := <-ch: fmt.Println("收到任务:", v) case <-quit: fmt.Println("收到退出信号") return } } }

select的case都是阻塞操作的，哪个channel先准备好，就走哪个分支。如果多个同时准备好，select会随机选一个执行，这可以防止某一个case被饿死。如果没有case准备好，且有default分支，就立即执行default；如果没有default，select会一直阻塞，直到有case就绪。

一个非常常见的用法是用select实现“超时控制”：

func doWithTimeout(ch chan string, timeout time.Duration) { select { case res := <-ch: fmt.Println("结果:", res) case <-time.After(timeout): fmt.Println("超时了") } }

time.After(timeout)会返回一个channel，这个channel在指定时间后收到一个time.Time值。于是select就能在“等结果”和“等超时”之间二选一。注意一点，time.After每次调用都会创建一个计时器，如果在循环里频繁调用，会带来额外的内存分配和GC压力。这种情况可以改用time.NewTimer和defer timer.Stop()来控制计时器生命周期。

3.4 关闭Channel：谁来关、怎么关、关了怎么处理

关闭channel是个说大不大说小不小的问题。正确的做法是：只在发送方关闭channel，接收方不要关。因为发送方关channel之后，接收方再读会得到零值，如果多读几次，你分不清这是正常数据还是关闭之后的零值。

接收方想要判断channel是否关闭，可以用两个返回值：

v, ok := <-ch if !ok { fmt.Println("channel 已关闭") return } fmt.Println("v =", v)

如果只用一个返回值接收，channel关闭后继续读会拿到零值，比如int就是0，string就是空串。不加判断就会产生逻辑bug，你可能会把“channel关闭”误当成“来了个0值任务”。

另外还有一种优雅的遍历写法：

for v := range ch { fmt.Println(v) }

range会在channel关闭后自动退出，不需要你自己判断ok。关闭channel之后再次关闭会导致panic，所以一般要配合sync.Once来保证只关闭一次，或者设计成单一的发送方。

这里分享一个我踩过的坑：当时某个微服务里有多个goroutine都在监听同一个任务channel，需求是任务完成后关闭channel来通知所有监听者。我直接用close(ch)，结果运行一段时间后突然panic，排查半天发现是另一个goroutine里也调用了close(ch)。后来加了sync.Once，并且把关闭职责收拢到独立的生命周期管理函数里，问题就没再出现过。在并发环境里，关闭channel这个动作一定不能多部门同时动手。

4. 并发三大常用工具：WaitGroup、Mutex、Atomic

4.1 WaitGroup：等所有goroutine跑完再继续

我们已经用过sync.WaitGroup来等goroutine执行完。这里细说一下它内部的原理和注意事项。

WaitGroup本质上是一个计数器。Add(delta)增加计数，Done()减少计数，Wait()阻塞直到计数归零。使用上有几个铁律：

• Add必须在Wait之前调用，而且最好放在goroutine启动前；
• Add的个数和Done的个数必须匹配，否则要么过早退出，要么永久阻塞；
• WaitGroup在计数为0后可以被复用，但不要跟正在进行的Wait交叉操作。

实际代码里容易翻车的写法是：

var wg sync.WaitGroup for i := 0; i < 10; i++ { go func() { wg.Add(1) defer wg.Done() // 干活 }() } wg.Wait()

Add被放进了goroutine内部，这就可能出现主goroutine执行到wg.Wait()时，所有子goroutine还没执行到wg.Add(1)，计数器还是0，于是直接往下走了，子goroutine还没来得及干活，程序就结束了。正确的姿势是：

var wg sync.WaitGroup for i := 0; i < 10; i++ { wg.Add(1) go func() { defer wg.Done() // 干活 }() } wg.Wait()

这一点一定要养成肌肉记忆。

4.2 Mutex：什么时候用锁，怎么避免死锁

channel虽然好用，但有些场景它就是不适合。比如多个goroutine只是读一个配置项、更新一个统计计数器，用channel反而啰嗦。这时直接用sync.Mutex更实在。

type SafeCounter struct { mu sync.Mutex count int } func (c *SafeCounter) Inc() { c.mu.Lock() defer c.mu.Unlock() c.count++ } func (c *SafeCounter) Value() int { c.mu.Lock() defer c.mu.Unlock() return c.count }

这里的关键点是defer c.mu.Unlock()。它保证了即使函数中途panic，锁也会被释放，避免锁泄漏导致其他goroutine全部卡死。如果不用defer，一旦某个分支忘记解锁，排查起来会非常痛苦。

Mutex使用中最常见的坑是不可重入。Go的Mutex不像Java的ReentrantLock，同一个goroutine不能对一个Mutex连续加锁两次，否则会死锁。举个例子：

type Counter struct { mu sync.Mutex count int } func (c *Counter) Inc() { c.mu.Lock() defer c.mu.Unlock() c.count++ } func (c *Counter) IncTwice() { c.mu.Lock() defer c.mu.Unlock() c.Inc() // 这里会死锁！ c.Inc() }

IncTwice已经持锁，再调Inc又去抢同一把锁，结果把自己锁死了。遇到这种需求，要么拆成不持锁的私有方法，要么用sync.RWMutex分别处理读写。

sync.RWMutex是读写锁：多个读锁可以同时持有，写锁是排他的。适合读多写少的场景。但这也带来潜在风险：如果读操作非常多，写锁可能长时间抢不到，导致写饥饿。这是需要结合实际压测去评估的。

4.3 Atomic操作：无锁编程的轻量方案

sync/atomic提供了一组原子操作，比如AddInt64、CompareAndSwapInt32、Load、Store等。它们比Mutex更轻，适合对单个数值变量做加减或更新的场景。

var counter int64 atomic.AddInt64(&counter, 1) fmt.Println(atomic.LoadInt64(&counter))

原子操作通过CPU指令实现，没有操作系统级别的阻塞，性能极好。但它们的适用范围也窄，只适合单个变量。如果逻辑跨多个变量，比如“先判断状态再更新”,那就得考虑用锁或者channel了。原子操作不是万能的，很多并发bug恰恰是程序员想用原子操作实现复杂逻辑结果用了个寂寞。

我见过一个比较典型的错误：用atomic.AddInt64累加多个计数器，结果不同计数器之间的一致性完全没保证。比如扣库存时先判断库存是否充足，再执行扣减，这两步之间如果有并发，库存就可能扣成负数。这种场景应该用atomic.CompareAndSwapInt64做乐观锁循环，或者直接加Mutex，才是正解。

5. 进阶控制：Context、并发模式与超时取消

5.1 Context：超时、取消、传递值的标准方案

当你的并发系统开始变大，比如一个请求要拆成好几个子任务并行执行，再由子任务触发子子任务，你就需要一种能顺着调用链传递“取消信号”的机制。Go里的标准答案就是context.Context。

Context最常用的场景是超时控制和主动取消。先看一个超时控制的例子：

ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) defer cancel() res, err := doWork(ctx) if err != nil { fmt.Println("任务失败或被取消:", err) return } fmt.Println("结果:", res)

这里的cancel函数很重要，尤其当doWork提前返回时，如果不调用cancel，context会一直存活到超时时间才释放，可能造成资源泄漏。所以**defer cancel()是标配**。

在子goroutine里，我们需要监听context的取消事件：

func doWork(ctx context.Context) (string, error) { for { select { case <-ctx.Done(): return "", ctx.Err() default: // 执行一小步工作 } } }

ctx.Done()返回的channel会在context被取消或超时后关闭，我们就能及时退出。这种模式在网络请求、数据库调用、任务队列处理中极其常见，算是Go并发进阶第一课。

5.2 并发模式一：Worker Pool 工作池

在实际业务中，我们很少无脑开几万个goroutine，通常是开一组固定数量的worker，反复从任务队列里取任务执行。这样做的原因很简单：goroutine虽便宜，但频繁创建销毁也有调度和内存开销；更重要的是，如果同时并发数太高，下游数据库或者第三方接口根本扛不住。

一个典型的工作池实现：

type Task struct { ID int Payload string } func main() { const numWorkers = 3 tasks := make(chan Task, 100) results := make(chan string, 100) // 启动工人 var wg sync.WaitGroup for i := 1; i <= numWorkers; i++ { wg.Add(1) go func(id int) { defer wg.Done() for task := range tasks { // 模拟处理 results <- fmt.Sprintf("worker %d 处理了任务 %d", id, task.ID) } }(i) } // 派发任务 for i := 1; i <= 10; i++ { tasks <- Task{ID: i, Payload: "hello"} } close(tasks) // 等待工人完成 go func() { wg.Wait() close(results) }() // 读取结果 for r := range results { fmt.Println(r) } }

这里有几个设计细节值得注意：任务用有缓冲channel接收，能吸收生产端的突发流量；所有worker通过range tasks消费，任务channel关闭后worker会自动退出；结果通过另一个channel收集，等所有worker退出后关闭。

工作池代码看起来简单，但有个隐藏的坑：如果worker在执行任务时panic，整个程序会崩溃，而且Done不会执到，wg.Wait()会一直等下去。所以生产级代码里，每个worker内部要套一层recover，记录日志，再决定是继续还是退出。这个问题我后面还会提到。

5.3 并发模式二：Fan-out / Fan-in 扇出与扇入

扇出（fan-out）指一个数据源的数据被多个goroutine并行处理；扇入（fan-in）指把多个goroutine产生的结果汇总到一个channel里。

这种模式在数据处理管道里很常见。比如有一个来源id列表，需要并行调用外部API拿结果，再汇总展示。常规写法是：

func fanOutFanIn(ids []int) []string { input := make(chan int) output := make(chan string, len(ids)) // 扇出：多个worker处理id var workers sync.WaitGroup for i := 0; i < 4; i++ { workers.Add(1) go func() { defer workers.Done() for id := range input { output <- fetchData(id) } }() } // 生产端：把id送入input go func() { for _, id := range ids { input <- id } close(input) }() // 等workers都处理完，关闭output go func() { workers.Wait() close(output) }() // 扇入：从output收集所有结果 var result []string for s := range output { result = append(result, s) } return result }

扇入扇出最大的优势是能让数据在整个管道里并行流动，而不是等一批算完再算下一批。你要注意的是output的容量：如果结果没地方放，worker会被阻塞在output <-上，而此时主协程正在等output关闭，就可能出现死锁。把output设为有缓冲，容量等于总任务数，问题就没了，但是内存占用需要权衡。

5.4 错误处理与Panic恢复

并发环境下，最让人头疼的问题之一就是panic。一个goroutine里如果发生未捕获的panic，整个进程直接崩，不管其他goroutine有没有事。所以如果你在写后台服务，必须给goroutine的入口函数加一层保护。

一个常用的恢复机制：

func SafeGo(fn func()) { go func() { defer func() { if err := recover(); err != nil { log.Printf("goroutine panic: %v", err) } }() fn() }() }

有了这层兜底，至少单点goroutine崩溃不至于拖垮整个服务。但这里只解决了“不崩溃”的问题，没解决“任务丢了”的问题。所以生产中更稳妥的做法是引入重试机制和消息持久化，把panic的任务记录下来，稍后补偿处理。我不建议过度依赖recover隐藏问题，它应该被当作最后一道保险，而不是主要错误处理手段。

另外一个问题是：goroutine里出现的error，如果只是log.Println打一下，上层根本感知不到。正确的做法是把error通过channel返回，或者存进errgroup.Group。golang.org/x/sync/errgroup是官方扩展包，它允许并行执行一组goroutine，并且当其中一个返回error时，可以自动取消其他任务。

g, ctx := errgroup.WithContext(context.Background()) for _, task := range tasks { task := task g.Go(func() error { select { case <-ctx.Done(): return ctx.Err() default: return execute(task) } }) } if err := g.Wait(); err != nil { log.Println("任务组失败:", err) }

这个包我强烈建议加入工具箱，比裸写sync.WaitGroup + channel优雅多了。

6. 并发排查与性能调优实录

6.1 死锁案例复盘：两个goroutine互相等

死锁是并发编程里最经典的问题，Go里也有个特点：如果程序死锁，runtime会直接检测到并报fatal error: all goroutines are asleep - deadlock!，然后打印堆栈。所以Go死锁其实挺好发现的，难在怎么从堆栈里定位到具体哪两处。

我复盘一个很常见的死锁场景：

func main() { ch := make(chan int) go func() { ch <- 1 }() // 主goroutine在接收前就Wait，导致没有接收方 time.Sleep(time.Second) <-ch }

这段代码里，子goroutine发数据到无缓冲channel，会阻塞；主goroutine先Sleep再接收。如果Sleep期间没有任何其他产生接收的代码，子goroutine就一直在阻塞，主goroutine睡醒后就会去收。所以这里未必死锁，因为主goroutine后面还是会接收。真正的死锁是两边都等待对方先行动，而且谁也等不到。

比如：

ch1 := make(chan int) ch2 := make(chan int) go func() { <-ch1 ch2 <- 1 }() <-ch2 ch1 <- 1

主goroutine在等ch2的数据，子goroutine在等ch1的数据，两个人都想先拿到对方手里的东西再交出自己手里的，于是卡死。这种问题在设计跨goroutine的环形依赖时特别容易出现，排查思路就是看堆栈里每个goroutine阻塞在哪个channel上，理清谁在等谁。

预防死锁的几条经验：一是尽量减少channel层级，别搞太深的流水线；二是对所有可能阻塞的操作设置超时，比如用select加time.After；三是画一张简单的数据流图，标注清楚每个channel的生产者和消费者，避免成环。

6.2 数据竞态检测：一个工具抓出一堆bug

数据竞态（data race）指的是多个goroutine同时访问同一个变量，并且至少一个是写操作，而访问顺序没有同步。它不像死锁那么明显，程序可能跑100次只出1次错，是最难排查的并发问题之一。

好在Go自带一个race detector，用起来非常简单：

go run -race main.go go build -race main.go

只要给go run或go build加上-race标志，运行时就会检测数据竞态，并在发生问题时打印warning和堆栈。通常在做单元测试或者压测时，我都会至少跑一次带-race的版本，哪怕牺牲一点性能，也要把隐患暴露出来。

举个例子：

var count int func main() { for i := 0; i < 1000; i++ { go func() { count++ // 数据竞态 }() } }

用go run -race main.go运行，立刻就能看到类似WARNING: DATA RACE的输出，并明确指出哪一行有冲突。修复方式就是加锁、用atomic，或者改成channel。race detector在开发阶段是无价之宝，但记住它只能检测运行时实际发生的竞态，如果某个代码路径压根没跑到，它照样查不出来，所以测试覆盖率很重要。

6.3 用pprof找出“耗时的goroutine在干什么”

当系统并发量上来之后，光“能跑”是不够的，还得“跑得快”。Go标准库提供了runtime/pprof和net/http/pprof，可以非常方便地拿到CPU profile、内存堆、goroutine堆栈等数据。

最常用的方式是在代码里匿名导入：

import _ "net/http/pprof"

然后启动一个HTTP服务：

go func() { http.ListenAndServe("localhost:6060", nil) }()

接着在浏览器或者命令行里访问：

go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 go tool pprof http://localhost:6060/debug/pprof/heap go tool pprof http://localhost:6060/debug/pprof/goroutine

以goroutine为例，如果你想看程序当前所有goroutine的堆栈，可以用：

go tool pprof -top http://localhost:6060/debug/pprof/goroutine

我一次线上排查里，发现服务每隔几分钟延迟就飙一下，pprof抓到的goroutine堆栈里一堆阻塞在channel receive上的协程，再去反查它们等的channel，定位到一个未及时关闭的有缓冲channel，缓冲被填满后生产者阻塞，后面的任务全部排队。后来把缓冲调大，并增加了消费者数量，延迟就降下来了。

关于性能调优，我个人的建议是：先测量，再优化。不要凭感觉猜瓶颈。pprof的火焰图能直观地看到哪个函数占用CPU时间最长，memory profile能看到哪个地方分配了大量对象。很多时候你以为性能瓶颈在并发控制，查出来却是一个没必要的fmt.Sprintf或者频繁的字符串拼接，换用strings.Builder就解决了一大半。

6.4 常见并发问题速查表

我这几年做Go并发相关的Code Review，遇到最多的问题基本可以归成以下几类。整理一个速查表，方便你排错的时候对照。

这些坑写出来一条一条看着很简单，但实际环境里它们往往组合出现，排查起来会绕很多弯路。我习惯的做法是：任何时候发现诡异行为，第一件事不是改代码，而是先跑go run -race，再看pprof，让数据说话。

6.5 写在最后：一点个人体会

Go的并发模型确实是我用过所有语言里最“顺手”的，但顺手不代表不需要思考。我见过不少项目，goroutine开得飞起，结果代码变成一团乱麻，拿日志一看全是协程互相踩脚。所以说，掌握语法只是入门，真正的进阶是学会控制复杂度：控制goroutine的数量、控制channel的方向、控制任务的超时和取消、控制全局变量的访问边界。

从我个人的经验来看，学Go并发编程最好的路径，不是刷一堆理论，而是拿一个真实场景反复练手。你可以从最简单的并发下载器开始，逐步加限制：加超时、加取消、加工作池、加错误恢复，最后再压测和调优。每一步都会踩到不同类型的坑，但踩完一次，你就会对Go的调度和同步机制理解得更深一层。

这篇文章从Goroutine和GMP调度模型，讲到了Channel、WaitGroup、Mutex、Atomic，再到Context、工作池、扇入扇出、错误处理，最后聊了死锁排查、数据竞态和pprof调优，基本覆盖了Go并发从入门到实战的主干内容。如果你照着代码敲一遍，把每个例子的运行结果都看明白，再自己改造几个变体，我敢说你已经超过了绝大多数刚接触Go的工程师。剩下的，就是在真实项目里不断打磨了。