刚学 Go 那会儿，我一度觉得 goroutine 这东西简直玄幻。写个 go func() 就并发执行了？还那么轻量？直到后来在生产环境碰上诡异的延迟抖动，才发现——这玩意儿的调度机制，远不是“比线程快”那么简单。
说实话，大部分资料都在讲 goroutine 多么便宜，却很少触及它为什么便宜，以及便宜背后的代价。比如，你随手开十万个 goroutine，内存压测曲线依然平滑——但这不代表它们真的在并发干活。有些时候恰好一堆 goroutine 躲在某个 P 的本地队列里饿着，调度器还假装岁月静好。
GMP 调度器：不止是“M 比 N”那么简单
先抛开那些教科书式的 M:N 模型。Go 的调度器核心是 G、M、P 三兄弟。G 是 goroutine，M 是操作系统线程，P 是 processor——一个抽象的执行资源。为什么要引入 P？因为只有把调度和线程解耦，才能实现 work stealing 和 hand off 这种骚操作，对吧？
我理解的类比：一个工厂车间。M 是真正干活的工人，P 是工作台，G 是待处理的工件。每个工作台配一个工人。工作台数量用 GOMAXPROCS 控制，默认等于 CPU 核数。每个 P 有自己的 local runqueue（本地队列），新创建的 G 通常放进去。当本地队列空了，工人就从其他 P 的队列里偷一半任务——这就是 work stealing，图示理解起来挺直观的。
但这里有坑：全局队列（global runqueue）优先级低，容易被饿死。有些 G 在系统调用时阻塞，M 会暂时带着 P 剥离，新 M 被创建顶上，避免 P 闲着。可是如果大量阻塞型系统调用，M 数量可能暴增，调度开销跟着飞涨。曾经压测一个 gRPC 服务，客户端故意慢消费，结果 M 飚到上千，CPU 都在内核态打转。这才明白，调度器不是银弹。
再深入一点，goroutine 的栈是动态增减的，起始只有 2KB，按需扩展。这比线程固定的 1MB 栈省太多内存。但栈分裂和收缩的过程涉及栈拷贝，如果恰好你的 goroutine 持有指针指向栈内对象，拷贝后指针失效——Go 运行时靠精确的栈扫描和写屏障来修正，这技术细节够写篇论文。普通开发者不需要懂，但至少要知道，频繁的栈扩缩会带来内存分配和拷贝的抖动，尤其在递归或深层函数调用链中。
数据不会说谎：goroutine 到底多轻量？
嘴上说轻量没用，直接上压测数据。一次在 16 核机器上对比，创建 10 万个线程？系统直接 OOM。而 10 万个 goroutine，内存占用仅约 800MB 左右（每个 goroutine 的初始栈 + 运行时元数据）。单就创建耗时，批量创建时 goroutine 的延迟几乎线性微增，线程则呈指数级恶化。
另一个案例：用 Go 实现的 TCP 网关，sync pool 搭配 goroutine + channel 管道模型，长连接 50 万，稳态下 CPU 使用率 30%，内存 2.3GB。同等连接数，如果用传统线程池（如 C++ 基于 pthread），早就撑爆了。更关键的是，goroutine 的调度点是协同的——在 channel 操作、系统调用、函数调用前（更准确说是栈增长检查）插入抢占点。这避免了频繁内核态上下文切换，实测切换开销低至几十纳秒级。
不过，别被平均数据忽悠。一旦大量 goroutine 阻塞在 非网络 I/O 的系统调用（比如文件 IO），由于 Go 没把这类调用集成到 netpoller，只能靠创建新 M 来扛，上下文就变成内核态切换，性能锐减。所以，高并发场景里，文件 IO 最好用异步方式或者单独线程池隔离，这是后话。
三个血泪坑点与最佳实践
坑一：Goroutine 泄漏
最常见。例如，你写了个生产者消费者模式，消费者从 chan 读数据，中途出错直接 return，那个 goroutine 就永远吊在那里，占用内存和调度资源。如果生产端还在写，最终 channel 满，生产者都堵死。解决方案？永远用 context 传递取消信号，或者在 goroutine 内监听外部的 done channel。规矩就是：谁创建谁负责生命周期，用一个 sync.WaitGroup 收尾。
坑二：裸用 map 的并发读写
Go 的内置 map 不是并发安全的。多个 goroutine 同时写，直接 fatal error: concurrent map writes，服务秒崩。即使一个写一个读也不行。我们吃过亏。解决方案：读多写少用 sync.RWMutex 配 map，写频繁则直接用 sync.Map，它内部做了分区和读写分离。还有一种奇技淫巧：如果 key 是稳定的，可以分片加锁，把大 map 打散成多个小 map，降低锁竞争。
坑三：GOMAXPROCS 的误解
有人以为把 GOMAXPROCS 调大就万事大吉。单机上跑多个 Go 服务时，每个服务默认用满所有核，结果相互抢占，上下文切换反而更多。正确做法：容器环境下，用 runtime.GOMAXPROCS(int) 设置等于容器核数限制，或者利用 Uber 的 automaxprocs 库自动适配 cgroup 限制。另一个极端：GOMAXPROCS=1 时，调度器变成了协作式，如果一个 goroutine 不主动让出（比如死循环），其他 goroutine 压根没机会执行。所以关键循环里要插入 runtime.Gosched()，或用 channel 操作触发调度点。
说到底，Go 的并发模型让开发者不用直面内核线程，但底层误解会带来诡异的运行时问题。理解调度器的脾气，才能写出真正高吞吐的服务。这大概就是所谓的“工程美学”吧——隐藏复杂性，但决不消除复杂性。
附：上述实践在我们团队的高频交易网关里跑了大半年，从最初的坑到现在的稳定，都是真金白银换来的经验。如果你也在深水区扑腾，建议看看 runtime/trace 和 pprof，它们比任何文章都有说服力。
