直接起goroutine处理请求会导致内存暴涨、调度过载甚至oom,因go不限流且goroutine有栈开销;应使用带缓冲channel+固定worker池限流,并结合context与errgroup实现超时控制和优雅退出。

为什么直接起 goroutine 处理请求会崩
大量并发请求下,go handleRequest(req) 会无节制创建 goroutine,内存暴涨、调度器过载、甚至 OOM。Go runtime 不会自动限流,runtime.GOMAXPROCS 控制的是 OS 线程数,不是 goroutine 并发上限。
- 典型现象:
fatal error: runtime: out of memory或schedule: holding locks日志 - 根本原因:goroutine 是轻量级,但仍有栈内存(默认 2KB)、调度开销、GC 压力随数量线性上升
- 正确思路:用 channel 做任务队列 + 固定数量 worker goroutine 消费,实现可控并发
用 buffered channel + worker pool 实现限流
核心是把请求封装为任务,投递到带缓冲的 chan *http.Request(或自定义任务结构),由固定数量的 worker 从 channel 中取任务执行。
type WorkerPool struct {
tasks chan *http.Request
workers int
}
<p>func NewWorkerPool(size int) <em>WorkerPool {
return &WorkerPool{
tasks: make(chan </em>http.Request, 1000), // 缓冲区防阻塞生产者
workers: size,
}
}</p><p>func (wp *WorkerPool) Start() {
for i := 0; i </p><p>func (wp <em>WorkerPool) Submit(req </em>http.Request) {
select {
case wp.tasks </p>
-
make(chan *http.Request, 1000)的缓冲大小需根据平均处理时长和 QPS 估算,太小易丢任务,太大吃内存 -
select {... default: ...}是非阻塞提交的关键,避免 handler 卡死 - worker 数量通常设为
runtime.NumCPU() * 2左右,过高反而因上下文切换降低吞吐
用 errgroup + context 控制超时与取消
单纯 channel 池无法优雅中断正在运行的任务。需结合 context.Context 和 errgroup.Group 实现整体超时与传播取消信号。
func (wp *WorkerPool) SubmitWithContext(ctx context.Context, req *http.Request) error {
// 包装请求上下文,携带超时与取消
req = req.WithContext(ctx)
<pre class="brush:php;toolbar:false;">select {
case wp.tasks <p>}</p><p>// 启动时改用 errgroup
func (wp <em>WorkerPool) StartWithGroup(g </em>errgroup.Group) {
for i := 0; i </p>
-
req.WithContext(ctx)确保下游 DB、HTTP 客户端等能感知超时 -
errgroup可统一等待所有 worker 退出,并捕获任意 worker panic 或 error - 注意:channel 关闭后
req, ok := 中 <code>ok为 false,应退出 goroutine
别忽略 HTTP Server 层的连接与读写限制
goroutine 池只是应用层限流,若底层 TCP 连接不控,仍可能被慢连接打垮。必须配置 http.Server 的各项超时与限制。
server := &http.Server{
Addr: ":8080",
Handler: myHandler,
ReadTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 30 * time.Second,
MaxHeaderBytes: 1 10000 → close)
}
},
}
-
ReadTimeout防慢请求头/体,WriteTimeout防慢响应,IdleTimeout防长连接耗尽 fd -
MaxHeaderBytes必须设,否则恶意大 header 可轻易触发 OOM - 真正高负载时,还需配合反向代理(如 nginx)做连接排队、TLS 卸载、IP 限流等
goroutine 池的边界很清晰:它只管“我有多少个工人能同时干活”,不管“谁来敲门”“门开了多久”“进门后赖着不走”。漏掉任一层,都可能让精心设计的池子毫无意义。
golang免费学习笔记(深入):立即使用
在学习笔记中,你将探索golang的核心概念和高级技巧!











