Golang控制goroutine并发数方法

本文深入浅出地讲解了在Go语言中如何用 `chan struct{}` 实现轻量高效的goroutine并发数控制——通过创建固定容量的缓冲通道来“占位”和“归还”，天然实现阻塞式限流，既简单又高性能；但同时严肃提醒：一旦忘记归还（如panic未recover或提前return），通道将被占满导致后续goroutine永久阻塞、服务卡死，因此虽原理清晰、性能优异，却极不推荐在生产环境裸写，务必搭配严谨的错误处理与资源清理机制。

用 chan struct{} 控制并发数：最轻量但最易翻车

直接上结论：能用，够快，但一漏释放就卡死，生产环境不建议裸写。

原理很简单：make(chan struct{}, 10) 创建一个容量为 10 的缓冲通道，每次 goroutine 启动前往里写一个 struct{}{}（占位），执行完再读一个（归还）。满时写操作自动阻塞，天然限流。

• 必须用 struct{}，别用 chan int —— 后者容易误判 0 值、多占内存，且语义不清
• defer func() { 必须写在 goroutine 内部，且显式传参；匿名函数里闭包 sem 没问题，但闭包 item 很可能出错
• 别在 select 里只写 case 就开干 —— 如果任务 panic，defer 还没注册就退出，令牌永远丢失
• len(sem) 不是“剩余可用数”，是“已占未放”的数量；真要查可用槽位得用 cap(sem) - len(sem)，但一般没必要

改用 golang.org/x/sync/semaphore：官方推荐，安全有保障

这是目前 Go 生态最稳妥的选择，由 Go 官方维护，支持上下文超时、权重、非阻塞尝试，panic 时也能保证释放。

初始化：sem := semaphore.NewWeighted(5)，参数是 int64，别传负数或 0。

• sem.Acquire(ctx, 1) 必须检查返回 error —— 若 ctx 超时或取消，会立刻返回 context.DeadlineExceeded 或 context.Canceled，此时不能继续执行业务逻辑
• 务必配 defer sem.Release(1)，哪怕 handler panic，Go runtime 也会执行 defer，令牌不会泄漏
• 如果想快速失败（比如限流后直接返回 429），用 sem.TryAcquire(1)，它不阻塞、不等、不看 context，成功返回 true，否则 false
• 别在每个 HTTP handler 里 new 一个 semaphore —— 它该是全局单例，生命周期和 server 一致

什么时候该换 worker pool，而不是只做信号量？

信号量只管“同时跑几个”，不管“谁来跑”“跑几次”“失败了怎么办”。一旦你遇到这些情况，就得升维到 worker pool：

• 任务需要复用资源（如 DB 连接、HTTP client、TLS session）
• 要控制排队行为（比如任务积压时拒绝新请求，而非无限等待）
• 需统计指标（当前运行数、排队数、平均耗时）
• 任务执行时间差异大，某些长期 hang 住（比如第三方接口不响应），光靠信号量无法主动熔断

这时候推荐 github.com/panjf2000/ants：它预启固定数量 goroutine 持续消费任务队列，支持 panic 捕获、超时控制、动态伸缩。注意别把任务队列设成无缓冲 channel —— 容易 OOM；也别让 worker 数远小于任务量又不设缓冲，会导致任务被丢弃。

别混淆 runtime.GOMAXPROCS 和并发控制

runtime.GOMAXPROCS 控的是 OS 线程（P）数量，不是 goroutine 并发数。设成 1，1000 个 goroutine 仍会调度执行，只是不能并行利用多核 —— 它们全挤在一个 P 上快速切换。

真正影响并发上限的，只有你写的信号量、worker pool 或第三方库的配置项。

常见错误是看到 CPU 利用率低，就盲目调高 GOMAXPROCS，结果发现 HTTP 超时更多、DB 连接池打满 —— 因为问题根本不在 P 数，而在没控好 goroutine 数量本身。

最常被忽略的一点：限流之后，一定要有兜底观测。比如加个 pprof endpoint，定期看 goroutines 数是否缓慢上涨；或者用 semaphore 的 CurrentCount()（需自己封装）暴露指标。没有监控的限流，就像没刹车的车。

以上就是《Golang控制goroutine并发数方法》的详细内容，更多关于的资料请关注golang学习网公众号！