如何使用Golang semaphore实现并发限制_控制同时执行任务数量
Go语言无内置信号量，推荐使用golang.org/x/sync/semaphore包实现并发控制，支持Acquire/Release操作与上下文取消；也可用带缓冲channel模拟二进制信号量。
Go 语言本身没有内置的信号量（semaphore）类型，但可以通过 sync.WaitGroup + chan struct{} 或更推荐的方式 —— 使用标准库中的 golang.org/x/sync/semaphore 包来实现精确的并发数限制。
使用 x/sync/semaphore 实现并发控制
这是最简洁、线程安全且语义清晰的做法。该包提供了一个带权重的信号量，支持 Acquire/Release 操作，适合控制同时运行的 goroutine 数量。
- 安装依赖：
go get golang.org/x/sync/semaphore - 创建信号量：传入最大并发数（如 5），表示最多允许 5 个 goroutine 同时持有许可
- 每个任务开始前调用
sem.Acquire(ctx, 1)获取一个许可；完成后必须调用sem.Release(1)归还 -
Acquire是阻塞操作，若无可用许可会等待；支持上下文取消，可及时退出
示例代码：
package mainimport ( "context" "fmt" "log" "time" "golang.org/x/sync/semaphore" )
func main() { sem := semaphore.NewWeighted(3) // 最多 3 个并发 ctx := context.Background()
for i := 0; i < 10; i++ { i := i go func() { if err := sem.Acquire(ctx, 1); err != nil { log.Printf("acquire failed: %v", err) return } defer sem.Release(1) fmt.Printf("task %d started\n", i) time.Sleep(time.Second * 2) // 模拟耗时操作 fmt.Printf("task %d done\n", i) }() } // 等待所有 goroutine 完成（实际项目中建议用 WaitGroup 配合） time.Sleep(time.Second * 8)
}
立即学习“go语言免费学习笔记（深入）”；
用 channel 模拟二进制信号量（简单场景）
如果不想引入外部依赖，可以用带缓冲的
chan struct{} 实现简易版信号量，适用于固定权重（每次申请/释放 1 单位）的场景。
eturn
}
defer sem.Release(1)
fmt.Printf("task %d started\n", i)
time.Sleep(time.Second * 2) // 模拟耗时操作
fmt.Printf("task %d done\n", i)
}()
}
// 等待所有 goroutine 完成（实际项目中建议用 WaitGroup 配合）
time.Sleep(time.Second * 8)- 声明：
sem := make(chan struct{}, maxConcurrency) - 获取许可：
sem （满时阻塞） - 释放许可：
- 注意：不能响应 context 取消，也不支持非阻塞尝试获取（需额外逻辑）
示例片段：
sem := make(chan struct{}, 2)
for i := 0; i < 6; i++ {
go func(id int) {
sem <- struct{}{} // 获取许可
defer func() { <-sem }() // 释放许可
fmt.Printf("working on %d\n", id)
time.Sleep(time.Second)
}(i)}
立即学习“go语言免费学习笔记（深入）”；
常见陷阱与注意事项
信号量只是并发控制工具，不解决数据竞争或任务协调问题，使用时需格外注意：
- 务必确保每个
Acquire 都有对应的Release，否则会导致许可泄露、后续任务永久阻塞 - 在错误路径或 panic 前未释放许可？用
defer是最稳妥的方式 - 不要混用不同信号量实例控制同一类资源，容易误判并发水位
- 若任务耗时差异大，单纯限制 goroutine 数量可能无法均衡负载，可结合 worker pool 模式优化
何时该用 semaphore 而不是 worker pool？
两者适用不同模式：
- 用 semaphore：你已有大量 goroutine（比如 HTTP handler 中启动），只需“闸门式”限流，不关心任务排队或复用
- 用 worker pool：需要复用固定数量 goroutine 处理队列任务，强调吞吐可控、内存友好、支持优雅关闭
多数 API 限流、下游调用节流场景，x/sync/semaphore 更轻量直接；后台批处理、消息消费等长期运行任务，worker pool 更合适。
