Golang如何控制goroutine数量_Go语言并发优化实战

用带缓冲的chan Struct{}模拟信号量可精准控制goroutine并发数；初始化sem := make(chan struct{}, maxWorkers)，发送空结构体占位、接收释放，避免用chan int或close()引发panic。

用 semaphore 控制 goroutine 并发数最直接

Go 没有内置的“最大 goroutine 数”开关，但用带缓冲的 chan struct{} 模拟信号量是最轻量、最可控的方式。它本质是限制同时进入临界区的 goroutine 数量，不阻塞调度器，也不依赖第三方库。

常见错误是把 chan int 当计数器用，或误用 close() 导致 panic；正确做法是只用它作令牌桶：发送空结构体占位，接收即释放。

• 初始化：sem := make(chan struct{}, maxWorkers)，maxWorkers 即最大并发数
• 启动任务前：sem （若满则阻塞）
• 任务结束时：（必须在 defer 或结尾显式调用）
• 不要用 len(sem) 判断剩余容量——它只反映当前缓冲中元素个数，不是可用槽位数

sync.WaitGroup + semaphore 组合才能安全等全部完成

只靠信号量无法知道所有任务是否结束，必须配 sync.WaitGroup。漏掉 wg.Done() 或提前 wg.Wait() 都会导致死锁或 panic。

典型场景是批量 HTTP 请求、文件处理、数据库批量写入——既要限流，又要等结果汇总。

立即学习“go语言免费学习笔记（深入）”；

func processItems(items []string, maxWorkers int) {     sem := make(chan struct{}, maxWorkers)     var wg sync.WaitGroup 
for _, item := range items {     wg.Add(1)     go func(s string) {         defer wg.Done()         sem <- struct{}{}>
}
 
别用 runtime.GOMAXPROCS 控制并发数量
 
runtime.GOMAXPROCS 控制的是**OS 线程数上限**（即 P 的数量），不是 goroutine 并发数。设成 1 不会让 1000 个 goroutine 串行执行——它们仍会排队在单个 P 上快速切换，只是无法并行利用多核。
 
真正影响吞吐的是 I/O 阻塞、锁竞争、内存分配压力，而不是 P 的数量。盲目调小 GOMAXPROCS 可能反而加剧调度延迟。
 
 
默认值已是 NumCPU()，通常无需修改
 
仅当程序大量绑定系统线程（如 CGO 调用）且出现线程耗尽时才考虑调整
 
goroutine 数量由业务逻辑和 channel 阻塞行为决定，和 GOMAXPROCS 无直接关系
 
 
超时与取消必须配合 context.Context 
 
仅限流还不够。如果某个 goroutine 卡死（比如网络 hang 住、死循环），整个信号量池可能被占满，后续任务永久等待。必须为每个任务设置超时或可取消机制。
 
不能只在主 goroutine 里用 time.After，要将 ctx 传入子 goroutine，并在 I/O 操作中显式检查 ctx.Err()。
func fetchWithTimeout(url string, ctx context.Context) error {     req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)     resp, err := http.DefaultClient.Do(req)     if err != nil {         return err // 自动包含 context.Canceled 或 context.DeadlineExceeded     }     defer resp.Body.Close()     return nil }
注意：context.WithTimeout 返回的 cancel 函数要在 goroutine 启动后立即 defer 调用，否则可能泄漏 timer。