Go语言最大的卖点之一就是轻量级的并发能力，一个Goroutine的初始栈只有几KB，创建和销毁的开销远低于操作系统线程。但轻量不等于免费，如果无限制地创建Goroutine，或者误解了Goroutine与OS线程的关系，程序依然会在内存、调度甚至文件描述符上翻车。这篇文章从Go运行时的调度原理讲起，逐层拆解Goroutine与线程的映射关系，并给出几套在生产环境中验证过的并发管理策略。
一、先弄懂GMP模型：Goroutine和OS线程到底是什么关系
要理解Go的并发限制，绕不开GMP调度模型。G代表Goroutine，包含栈、指令指针以及对调度有用的状态信息；M代表Machine，也就是操作系统线程，是真正执行代码的实体；P代表Processor，是逻辑处理器，持有可运行Goroutine的本地队列，M必须绑定一个P才能执行G代码。
关键点在于：Goroutine运行在M之上，但一个M并不固定对应一个G。Go运行时的调度器会把大量G动态地分配到少量M上执行。GOMAXPROCS控制的是P的数量，默认等于CPU核心数。也就是说，无论你创建了一万个Goroutine，同一时刻真正在CPU上并行运行的Go代码，最多也只有GOMAXPROCS个。这个认知非常重要，很多性能问题都源于对它的误解。
另外要区分两类M：一类是执行用户Go代码的，数量受P约束；另一类是因系统调用或cgo而阻塞的M。当G陷入长时间的系统调用（比如读一个大文件）时，它绑定的M会一起被阻塞，调度器会把这个M和P解绑，唤醒或创建新的M继续执行其他G。这意味着M的数量可以远超GOMAXPROCS，极端情况下每个阻塞中的系统调用都可能占住一个线程，而每个线程默认有固定大小的栈（通常数MB），线程一多，内存压力就上来了。
package main
import (
"fmt"
"runtime"
)
func main() {
// 查看当前P的数量，默认等于CPU逻辑核心数
fmt.Println("GOMAXPROCS:", runtime.GOMAXPROCS(0))
// 查看当前的协程数量与线程数量
var ms runtime.MemStats
runtime.ReadMemStats(&ms)
fmt.Println("goroutines:", runtime.NumGoroutine())
}二、Goroutine虽然廉价，但限制到底在哪里
常说“一个Goroutine只有2KB”，这个说法要辩证看待。初始栈确实很小，但栈会按需增长，处理大切片、深递归的Goroutine栈可能膨胀到几MB。创建百万个Goroutine在内存上或许扛得住，但要考虑的不只是内存：每个Goroutine如果持有网络连接或文件句柄，瓶颈就转移到了fd数量；如果每个都在往channel里塞数据，锁竞争和GC压力会显著上升。
实际经验中，无节制并发的典型症状有三个：一是RSS内存持续上涨不回落，二是GC暂停时间变长、CPU被调度器本身吃掉，三是下游服务被打挂。第三个尤其常见——上游觉得“并发越高越快”，每秒创建几十万个Goroutine去请求数据库，数据库连接池瞬间耗尽，整体吞吐反而暴跌。并发度和吞吐量之间的关系是一个先升后降的曲线，找到拐点比盲目加并发重要得多。
还有一类隐蔽的问题是goroutine泄漏。一个Goroutine阻塞在无人写入的channel上，就永远退不出去，占着栈内存和调度资源。可以在测试中用runtime.NumGoroutine()做前后对比，或者用go vet、pprof的goroutine profile来排查泄漏点。
三、控制并发数量的四种实用策略
1. 带缓冲channel实现信号量
最简单的限流方式是利用带缓冲channel的容量作为信号量，任务开始前写入，结束后读出。代码不到十行，适合快速落地。
package main
import (
"fmt"
"sync"
)
func main() {
sem := make(chan struct{}, 100) // 最多100个并发
var wg sync.WaitGroup
for i := 0; i < 1000; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
sem <- struct{}{} // 获取信号量，满了就阻塞
defer func() { <-sem }() // 释放信号量
fmt.Println("working on", id)
}(i)
}
wg.Wait()
}这种写法有一个小缺陷：虽然同时运行的任务被限制了，但Goroutine本身还是提前创建了1000个，只是大部分阻塞在信号量上。对于任务量极大的场景，建议配合worker pool，直接限制Goroutine的创建数量。
2. worker pool固定工作协程数
worker pool的思路是反过来的：只创建固定数量的Goroutine作为工人，从任务channel里取活干。这样Goroutine数量恒定，内存可控，也便于复用连接等重资源。
package main
import (
"fmt"
"sync"
)
func main() {
tasks := make(chan int, 200)
var wg sync.WaitGroup
// 启动50个工人
for w := 0; w < 50; w++ {
wg.Add(1)
go func(worker int) {
defer wg.Done()
for t := range tasks {
fmt.Printf("worker %d handled task %d\n", worker, t)
}
}(w)
}
for i := 0; i < 10000; i++ {
tasks <- i
}
close(tasks) // 关闭后工人取完任务自动退出
wg.Wait()
}3. errgroup优雅管理成组任务
golang.org/x/sync/errgroup提供了带并发上限的WaitGroup增强版，还能在任一任务出错时取消整个组，是微服务扇出调用的首选。
package main
import (
"context"
"fmt"
"golang.org/x/sync/errgroup"
)
func main() {
g, ctx := errgroup.WithContext(context.Background())
g.SetLimit(64) // 组内最多64个并发
for i := 0; i < 1000; i++ {
i := i
g.Go(func() error {
select {
case <-ctx.Done():
return ctx.Err()
default:
fmt.Println("task", i)
return nil
}
})
}
if err := g.Wait(); err != nil {
fmt.Println("error:", err)
}
}4. 时间维度限流：RateLimiter
并发数限制解决的是“同时多少”，但有时要限制的是“每秒多少”。golang.org/x/time/rate基于令牌桶算法，适合保护下游API。它可以和前面的并发限制叠加使用，一个管瞬时并发，一个管速率，两者并不冲突。
四、压测与调优：怎么找到合适的并发数
并发参数不该拍脑袋定，推荐的做法是用压测工具（如wrk、vegeta）逐步提高并发度，同时用pprof观察三项指标：goroutine数量曲线、内存RSS、以及go tool pprof里的调度延迟。当吞吐量增长趋缓而延迟开始陡增时，那个点就是合理并发的上限。
对于CPU密集型任务，并发数设为GOMAXPROCS附近即可，多开只会增加调度开销；对于IO密集型任务，并发数可以设为“目标延迟内可完成的IO操作数”，通常远大于核心数，几百到几千都正常，关键看下游承受能力。容器环境下要特别注意GOMAXPROCS的设置：在Kubernetes中容器可能只分到2核，但Go默认按宿主机核心数设置P，造成大量无效切换，建议引入uber-go/automaxprocs自动修正，或者在部署时显式设置runtime.GOMAXPROCS(n)。
最后总结几条实践原则：Goroutine的创建要有明确的生命周期和退出条件；对外部资源的访问必须经过信号量或pool限制；上线前用goroutine profile确认没有泄漏；容器中校准GOMAXPROCS。把这些习惯养成之后，Go的并发能力才能真正为你的服务提速，而不是成为线上事故的源头。