goroutine 创建成本低但滥用仍会导致调度压力、GC负担和内存碎片；应复用临时对象（sync.Pool）、限制并发数量（worker pool）。
为什么 goroutine 创建成本其实不高，但滥用仍会出问题
Go 的 goroutine 是轻量级线程，底层由 GMP 调度器管理，创建开销远小于 OS 线程（通常仅需 2KB 栈空间 + 少量结构体）。但「成本低」不等于「零成本」——高频创建/销毁大量短命 goroutine 会显著增加调度器压力、GC 扫描负担和内存碎片。尤其在高并发 I/O 密集型服务中，go func() { ... }() 写在循环里是典型隐患。
用 sync.Pool 复用 goroutine 对应的上下文对象
goroutine 本身无法复用，但其常携带的临时对象（如 bytes.Buffer、自定义请求上下文、解码器）可以。频繁 new 这些对象会触发 GC，间接拖慢 goroutine 启动速度。用 sync.Pool 缓存它们能减少堆分配。
var bufferPool = sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
func handleRequest(data []byte) {
buf := bufferPool.Get().(*bytes.Buffer)
buf.Reset()
buf.Write(data)
// ... 处理逻辑
bufferPool.Put(buf) // 归还，非必须但推荐
}
-
sync.Pool不保证对象一定被复用，GC 时会清空，适合「生命周期短、创建开销大」的对象 - 避免在
Put后继续使用该对象，Get返回的可能是脏数据，务必调用Reset或显式初始化 - 不要用
sync.Pool存储含 finalizer 或需精确释放资源的对象（如文件句柄）
用 worker pool 模式限制并发 goroutine 数量
直接为每个任务启一个 goroutine 容易失控。改用固定数量的 worker goroutine 从 channel 消费任务，既控制资源上限，又避免调度器过载。这是降低「goroutine 管理成本」最直接有效的手段。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func startWorkerPool(jobChan <-chan Job, workers int) {
var wg sync.WaitGroup
for i := 0; i < workers; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for job := range jobChan {
job.Process()
}
}()
}
wg.Wait()
}
- worker 数量不是越多越好：通常设为
runtime.NumCPU()的 1–4 倍，具体看任务是 CPU 密集还是 I/O 密集 - channel 缓冲区大小影响吞吐：无缓冲 channel 会阻塞 sender，有缓冲可削峰，但过大导致内存积压
- 注意 job 结构体是否包含大字段或指针，避免意外逃逸到堆上增加 GC 压力
避免在 hot path 上无节制启动 goroutine
HTTP handler、数据库回调、消息队列消费者等高频路径，每请求都 go f() 是危险信号。除了 worker pool，还可结合以下策略：
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.Gosched()主动让出时间片，替代新建 goroutine 做简单异步（仅适用于极轻量、无阻塞逻辑） - 对确定可并行的少量子任务（如 2–3 个独立 API 调用），用
errgroup.Group统一管控生命周期，比裸写go更安全 - 检查是否真需要并发：有时串行处理加缓存（如
sync.Map）比并发更高效，尤其当共享状态访问频繁时 - 用
pprof的goroutinesprofile 看实际 goroutine 数量分布，确认是否存在泄漏（长期不退出的 goroutine）
真正难的不是少开 goroutine，而是判断哪些该并行、哪些该串行、哪些该复用——这得靠压测数据和运行时 profile 说话，而不是凭感觉加 go 关键字。
