Golang 并发控制技巧分享

本文深入解析了 Go 语言中并发控制的核心实践，重点推荐 Go 1.21+ 标准库新增的 `sync.Semaphore`（尤其是 `semaphore.NewWeighted`），强调其在上下文取消、panic 安全释放、超时等待和竞态规避上的显著优势；同时对比剖析了易出错的手写计数器与带缓冲 channel 模拟方案——虽轻量兼容旧版本，却极易因缓冲声明错误、释放遗漏或闭包变量捕获不当导致卡死或资源泄漏，提醒开发者优先拥抱原生语义清晰、健壮可靠的 `sync.Semaphore`，并严格遵循 `int64` 初始化、`error` 检查、`defer Release` 最外层放置等关键使用规范。

用 semaphore.NewWeighted 控制 goroutine 并发数（Go 1.21+ 推荐）

Go 1.21 起标准库自带 sync.Semaphore，是目前最稳妥的选择：它天然支持 context 取消、panic 安全释放、超时等待，且无竞态风险。手写计数器或 channel 容易漏释放、卡死、无法响应取消。

• 初始化必须传 int64：比如限 8 个并发，写 semaphore.NewWeighted(8) 不行，得写 semaphore.NewWeighted(int64(8))
• sem.Acquire(ctx, 1) 必须检查返回 error —— 若 ctx 已取消或超时，会立刻返回 context.Canceled 或 context.DeadlineExceeded，此时不能继续执行业务逻辑
• defer sem.Release(1) 必须放在 goroutine 最外层函数内，确保 panic 时也能归还许可；别写在子函数里，闭包捕获错变量会导致释放失败
• 权重设为 1 即可满足大多数场景；只有当任务资源消耗差异大（如大文件上传 vs 小查询），才考虑用 Acquire(ctx, weight) 做加权控制

用 chan struct{} 模拟信号量（轻量兼容方案）

所有 Go 版本都可用，不依赖外部包，适合简单脚本或旧版项目。原理是用带缓冲的 channel 当“许可证池”，容量即最大并发数。但极易翻车，生产环境慎用裸实现。

• 声明必须带缓冲：sem := make(chan struct{}, 5)；写成 make(chan struct{})（无缓冲）会直接阻塞，起不到限流作用
• 获取许可用 sem （阻塞直到有空位），释放用 <-sem；千万别用 len(sem) 判断是否可用——它返回已占用数，不是剩余数
• 必须用 struct{}，别用 chan int 或 chan bool：前者语义不清、多占内存，后者可能被误判为 false 值而干扰逻辑
• 每个成功获取后，必须有且仅有一个对应释放；推荐封装成 defer func() { <-sem }()，但注意闭包变量捕获问题（如循环中用 item，得显式传参）

别把限流逻辑放错位置

限流必须落在真正消耗资源的那一刻，而不是 goroutine 创建时或循环体外。放错位置等于没限。

• HTTP 请求场景：限流代码必须在 http.NewRequest() 之后、client.Do() 之前；放在 for 循环开头只限制了 goroutine 启动速度，实际连接数仍可能爆表
• TCP 连接场景：唯一可靠位置是 ln.Accept() 成功后、交付 handler 前；别试图靠 http.Server.MaxIdleConns 或 runtime.GOMAXPROCS 控制——前者只管复用连接，后者只管 OS 线程数，和业务并发无关
• 别在 handler 内反复 new semaphore 实例；它该是全局单例，生命周期与 server 一致，否则每次请求都新建，限流完全失效
• 即使请求失败（如 client.Do() 返回 error），也要归还许可；defer 正好覆盖这个逻辑，无需额外分支判断

什么时候该换 worker pool 而不是只用信号量

信号量只回答“最多同时跑几个”，不解决“谁来跑”“排队怎么管”“失败了重试吗”“长期 hang 怎么熔断”。一旦出现这些需求，就得升维。

• 需要拒绝积压任务（而非无限排队等待）：信号量会一直阻塞，worker pool 可配 ants.WithNonblocking(true) 快速失败
• 要统计实时指标（当前运行数、排队长度、平均耗时）：裸信号量无法提供，ants 或自建 pool 可暴露这些观测点
• 任务执行时间差异极大，部分可能长期 hang（如第三方接口无响应）：信号量无法主动中断，需结合 context 超时 + 主动 cancel 通知内部逻辑退出
• 任务来源不可控（如用户上传脚本、HTTP body 解析后动态生成）：建议用 ants.WithPanicHandler 统一捕获 panic，避免一个错误拖垮整个池

真正容易被忽略的是：并发限制不是一次性配置，而是随资源瓶颈动态对齐的过程。比如 HTTP 客户端限流，得同时看目标服务的 QPS 上限、单次延迟、你本地的文件描述符限制（ulimit -n），三者取最小值才是安全上限。设高了打崩下游，设低了浪费吞吐，中间那个平衡点，得靠压测和监控定。

今天关于《Golang 并发控制技巧分享》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！