协程上下文切换成本在大多数Go服务中不构成瓶颈，但单机goroutine超10万且任务粒度达微秒级时，G-P-M调度开销（P队列争抢、cache失效、runtime.locks竞争）会显现；应通过worker池硬限并发、复用协程、避免高频阻塞来控制。
协程上下文切换成本在大多数 go 服务中并不构成瓶颈，但当单机 goroutine 数量持续超过 10 万、且任务粒度极细（如微秒级计算或空转）时，调度器开销会开始显现——关键不是“能不能用”，而是“怎么避免无意义切换”。
goroutine 数量暴增时为什么上下文切换变重
Go 调度器的 G-P-M 模型虽快（单次切换约 0.1 微秒），但高频切换仍会带来可观开销：P 队列争抢、G 状态频繁变更、cache line 失效、以及 runtime.locks 的隐式竞争。尤其当大量 goroutine 卡在 select、chan send/receive 或锁等待上时，调度器被迫频繁唤醒/挂起，实际吞吐反而下降。
- 典型现象：
runtime.mcall、runtime.gosched_m在 pprof CPU profile 中占比突增 - 不是所有 goroutine 都在“干活”：用
/debug/pprof/goroutine?debug=2查看，若大量状态为chan receive或semacquire，说明被阻塞而非计算 - 注意区分：协程切换 ≠ 线程切换。前者不进内核，但过度调度仍吃 CPU 和缓存带宽
用 worker 池硬限并发数，别让 goroutine 数随请求线性增长
这是最直接有效的控制手段。避免每个 HTTP 请求、每条消息、每个数据库行都起一个 goroutine —— 尤其当上游 QPS 达到几千时，goroutine 数可能瞬间冲到百万级，而真正能并行执行的只有 GOMAXPROCS 个。
- 用带缓冲的
chan func()做任务队列，启动固定数量（如 50～200）worker 协程消费 - worker 内部用
for job := range jobs { ... }持续复用，避免反复创建销毁 - 配合
sync.WaitGroup控制启停，关闭 channel 后 worker 自然退出 - 示例核心逻辑：
jobs := make(chan func(), 1000) for i := 0; i
减少阻塞点：慎用无缓冲 channel、避免短时锁竞争、批量处理 I/O
goroutine 一旦阻塞，就会被调度器移出运行队列，等资源就绪再放回——这个“进出”过程就是上下文切换的主因。阻塞越频繁、等待越短，切换越“毛躁”。
- 无缓冲
chan是隐形切换放大器：每次ch 都需等待接收方 ready，极易造成成对 goroutine 频繁挂起/唤醒 - 短临界区用
sync.Mutex没问题，但若锁内只做几纳秒赋值，考虑用原子操作atomic.StoreUint64替代 - I/O 操作（如日志写入、HTTP client 调用）尽量批量：用
bufio.Writer缓冲写入，用http.Transport.MaxIdleConnsPerHost复用连接，避免每次调用都触发系统调用+调度 - 网络轮询器（netpoll）本身高效，但若大量 goroutine 同时
Read同一连接，仍会引发调度器抖动；优先使用context.WithTimeout防止无限等待
复用 goroutine 处理连续小任务，而非“一任务一协程”
对高频低延迟场景（如 WebSocket 消息分发、metrics 批量上报），让单个 goroutine 循环处理多个任务，比反复启停更省。
- 结构上类似：
go func() { for { select { case msg := - 配合
time.Ticker做节流：比如每 10ms 批量拉取一次 pending 任务，而不是每来一个就 dispatch 一次 - 注意栈逃逸：循环内避免分配大量堆对象，否则 GC 压力会上升，间接加剧调度负担
- 这种模式下，goroutine 数量稳定可控，CPU 缓存局部性更好，实测在 50k+ QPS 下比同等负载的“每请求一 goroutine”降低约 15–20% 调度开销
真正容易被忽略的点是：很多人盯着 goroutine 数量看，却没检查它们是否真在 work——大量 goroutine 停在 chan send 或 netpoll 上，本质是逻辑设计导致的“伪并发”。优化的第一步，永远是用 /debug/pprof/goroutine?debug=2 看一眼真实状态，而不是先改代码。
