Golang并发请求限制技巧分享

积累知识，胜过积蓄金银！毕竟在Golang开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《Golang限制并发请求的常用方法》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

推荐用 golang.org/x/sync/semaphore 控制并发：NewWeighted 设置最大并发数，Acquire/Release 配对使用 defer 保证释放，支持超时与非阻塞 TryAcquire。

用 semaphore 控制并发请求数（推荐）

Go 标准库没有内置信号量，但可以用 sync.Mutex + sync.Cond 或第三方库（如 golang.org/x/sync/semaphore）实现。后者更轻量、语义清晰，是目前最主流的做法。

注意：不要自己手写带计数的互斥锁——容易漏掉 Unlock 或在 panic 时未释放，导致死锁或资源耗尽。

• semaphore.Weighted 支持非阻塞获取（TryAcquire），适合做快速失败判断
• 每个请求应对应一次 Acquire 和一次 Release，建议用 defer 保证释放
• 初始权重值即最大并发数，比如 semaphore.NewWeighted(10) 表示最多 10 个并发

import "golang.org/x/sync/semaphore"
<p>var sem = semaphore.NewWeighted(5)</p><p>func handleRequest() {
if err := sem.Acquire(context.Background(), 1); err != nil {
// 超时或上下文取消
return
}
defer sem.Release(1)</p><pre class="brush:php;toolbar:false;">// 执行实际请求逻辑
doHTTPCall()

}

用 channel 做固定容量的并发令牌池

本质是用带缓冲的 channel 当作“令牌桶”，每次请求前从 channel 取一个空位，完成后放回。简单直接，不依赖外部包，适合轻量场景。

缺点是无法设置超时等待、不能动态调整容量，且容易误用：chan struct{} 容量设错或忘记 close 后的读取会 panic。

• 必须初始化为带缓冲的 channel：make(chan struct{}, 10)
• 获取令牌用 select + default 可做非阻塞尝试
• 务必确保每次成功获取后都有对应的 send 回 channel，否则池子会逐渐枯竭

var token = make(chan struct{}, 3)
<p>func init() {
for i := 0; i < cap(token); i++ {
token <- struct{}{}
}
}</p><p>func handleRequest() {
select {
case <-token:
// 获取成功
defer func() { token <- struct{}{} }()
doHTTPCall()
default:
// 无可用令牌，快速失败
return
}
}</p>

用 worker pool 模式统一调度请求

当并发控制只是起点，后续还要做任务排队、优先级、重试、统计等，就该上 worker pool。它把“限制并发”变成“固定数量 goroutine 持续消费任务队列”，更易扩展和观测。

注意：别让 worker 数量远小于任务量又不加队列缓冲，会导致大量任务被丢弃；也别让队列无限增长，引发 OOM。

• worker 数量即最大并发数，通常设为 CPU 核心数或 IO 密集型场景下的经验值（如 10–50）
• 任务 channel 应设缓冲（如 make(chan *Request, 1000)），避免生产者阻塞
• 需显式关闭 channel 并等待所有 worker 退出，否则 range 不会结束

func startWorkerPool(n int, jobs <h3>别踩 <code>time.Sleep</code> 或 <code>runtime.Gosched</code> 的坑</h3><p>有人试图用休眠或主动让出调度来“限速”，这是无效的。它们既不限制并发数，也不控制资源占用，只拖慢单个 goroutine，反而可能因堆积更多 goroutine 加剧内存压力。</p><p>尤其要注意：在 HTTP handler 中用 <code>time.Sleep</code> 等待，会占用整个 goroutine 直到超时，而 Go 的 HTTP server 默认为每个请求启一个 goroutine——等于人为制造 goroutine 泄漏。</p>

• time.Sleep 是时间控制，不是并发控制
• runtime.Gosched 只建议用于防止长时间独占 P，不解决并发上限问题
• 真正要控的是“同时执行的请求数”，不是“请求之间隔多久”

真正难的不是选哪种方式，而是确定那个数字：最大并发数设成多少？它得结合下游服务的吞吐能力、本机 CPU/内存余量、请求平均耗时和 p99 延迟目标来反复压测，而不是拍脑袋填个 10 或 100。

好了，本文到此结束，带大家了解了《Golang并发请求限制技巧分享》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！