goroutine切换开销低，真正瓶颈是调度点触发、内存分配和GC压力；应优先用sync.Mutex而非unbuffered channel限流，善用sync.Pool复用对象并避免泄漏。
为什么 goroutine 切换开销其实不来自“切换”本身
Go 的 goroutine 切换开销被高估了——它不是传统线程上下文切换（寄存器+栈+TLB 刷新），而是协作式调度下的栈跳转，实际成本极低（几十纳秒）。真正拖慢并发性能的，是 runtime.gosched()、channel 阻塞、netpoll 等触发的调度点，以及频繁的 mallocgc 和栈扩容。
- goroutine 创建/销毁比切换更贵（需分配栈、初始化 g 结构体）
- 阻塞在
select或未缓冲chan上时，会真实挂起并让出 P，但这是必要行为，不是“开销”，而是设计取舍 - 大量小 goroutine + 频繁 channel 通信 → 内存分配压力 + 调度器竞争 + GC 压力上升
用 sync.Pool 缓冲高频 goroutine 生命周期
避免每次请求都 go func() {...}()，尤其在 HTTP handler 或循环中。改用复用机制控制 goroutine 数量和资源生命周期。
var workerPool = sync.Pool{
New: func() interface{} {
return &worker{done: make(chan struct{})}
},
}
<p>func getWorker() <em>worker {
w := workerPool.Get().(</em>worker)
w.reset() // 清理状态
return w
}</p><p>func putWorker(w *worker) {
workerPool.Put(w)
}</p>-
sync.Pool不保证对象一定复用，GC 会清理；适合短生命周期、创建开销大的对象 - 不要把含闭包或外部引用的函数塞进 Pool（易导致内存泄漏）
- 如果 worker 内部持有
http.ResponseWriter或*bytes.Buffer，必须显式 reset，否则脏状态污染后续使用
慎用 unbuffered channel 替代 mutex，它可能更重
常见误区：用 chan struct{} 控制并发数，以为比 sync.Mutex 更“Go 风格”。但 unbuffered channel 的 send/receive 是同步阻塞点，每次都要进入调度器判定是否就绪，而 sync.Mutex 在无竞争时是纯用户态原子操作（fast path）。
- 无竞争下
sync.Mutex.Lock()≈ 10ns；ch <- struct{}{}≈ 100–300ns（含调度判定） - 若只是保护一段临界区（如更新 map），优先用
sync.RWMutex或sync.Map - 只有需要解耦生产/消费节奏、或天然有等待语义（如任务分发）时，才用 channel
用 GOMAXPROCS 和 pprof 定位真实瓶颈
盲目调大 GOMAXPROCS 不会减少切换，反而可能加剧 OS 线程争抢和 cache line bouncing。关键看 go tool trace 中的 “Scheduler latency” 和 “Goroutines” 图谱。
立即学习“go语言免费学习笔记（深入）”；
- 运行时加
-gcflags="-m"看逃逸分析，避免 goroutine 捕获大对象导致堆分配 -
go tool pprof -http=:8080 ./binary http://localhost:6060/debug/pprof/goroutine?debug=2查看 goroutine 泄漏 - 若 trace 显示大量 goroutine 处于
runnable状态但迟迟得不到 P，说明 P 不足或存在长耗时非阻塞 CPU 计算（应拆成小块并插入runtime.Gosched()）
实际压测中，把 10k goroutine + unbuffered channel 的限流逻辑换成 semaphore.NewWeighted(10)（golang.org/x/sync/semaphore），QPS 提升 15–20%，GC pause 减少一半——因为后者完全避免 channel 调度路径，且基于 sync.Mutex fast path 实现。别为了“看起来更 Go”牺牲可测量的性能。
