17370845950

runtime.NumGoroutine() 是监控协程数最直接方式，需配合阈值检查、信号量限流、pprof定位及worker pool等结构化手段防控协程爆炸。

使用 runtime.NumGoroutine() 是监控 Go 程序中当前活跃协程数量最直接的方式，但它本身不防止协程爆炸——真正起作用的是配合它做主动检查、限流和资源控制。

基础用法：实时获取协程数

调用 runtime.NumGoroutine() 返回当前正在运行或处于等待状态（如阻塞在 channel、锁、syscall）的 goroutine 总数。它开销极小，可高频调用：

• 适合在日志、健康检查接口或定时任务中采集快照
• 注意：该数值包含 runtime 内部使用的 goroutine（如 GC、netpoll），通常占 5–20 个，需结合业务基线判断异常
• 示例：log.Printf("current goroutines: %d", runtime.NumGoroutine())

关键场景：在启动新协程前做守门人

不能只“看”不“拦”。应在创建 goroutine 的入口处加阈值判断，避免无节制 spawn：

• 定义安全上限（例如 5000），每次 go f() 前检查：if runtime.NumGoroutine() > 5000 { log.Warn("too many goroutines, skip task") }
• 更稳妥的做法是结合信号量（如 semaphore.NewWeighted(100)）统一管理并发度，比单纯数数字更可靠
• 对 HTTP handler、消息消费循环等高危入口尤其要加保护，避免请求洪峰触发协程雪崩

配合 pprof 定位泄漏源头

单纯告警不够，需快速定位谁在疯狂启协程：

• 启用 pprof：在服务中注册 net/http/pprof，访问 /debug/pprof/goroutine?debug=2 查看完整堆栈
• 重点关注长时间处于 select、chan receive 或 time.Sleep 的 goroutine，它们可能已“挂起”却未退出
• 用 go tool pprof 分析火焰图，识别高频创建 goroutine 的函数路径

长期治理：用结构化方式替代裸 go

预防比监控更重要。从编码习惯上减少失控风险：

• 避免在 for 循环里直接写 go doWork(i)，改用 worker pool 模式（固定 N 个消费者处理任务队列）
• 所有异步操作必须有超时或上下文控制：go func(ctx context.Context) { ... }(ctx)，并在内部监听 ctx.Done()
• 用 errgroup.Group 替代手动管理一组 goroutine，天然支持 cancel 和错误传播