17370845950

goroutine泄漏比性能差更致命，常见于未close channel、无限等待select或time.After未消费channel；应通过pprof监控，避免无限制启goroutine，改用限流worker pool，并确保select含default或case。

goroutine 泄漏比性能差更致命

高并发下性能上不去，八成不是 CPU 或内存瓶颈，而是 goroutine 没被回收。常见于忘记 close() channel、无限等待 select、或用 time.After 做超时却没消费其 channel。

• 用 pprof/goroutines 查看实时 goroutine 数量：启动时加 _ "net/http/pprof"，访问 /debug/pprof/goroutine?debug=2
• 避免在循环中无条件起 goroutine：

  for _, req := range requests {
      go handle(req) // ❌ 可能爆炸
  }

  改用带限流的 worker pool（如 semaphore.NewWeighted(10)）
• 所有带 select 的 goroutine 必须有 default 或 case ，否则可能永久阻塞

channel 使用不当会拖垮吞吐量

channel 不是万能队列，它本质是同步原语。高并发下滥用无缓冲 channel（make(chan int)）会导致大量 goroutine 频繁切换和锁竞争。

• 生产者消费者模型优先用带缓冲 channel：make(chan *Request, 1024)，缓冲大小按 P99 请求处理时长 × QPS 估算
• 不要用 channel 传大对象（如结构体副本），改传指针或 sync.Pool 复用
• 关闭 channel 前确认所有发送方已退出，否则 panic：send on closed channel
• 读取 cha

  

  nnel 时别只写 val := ，要判断是否关闭：val, ok := ，否则可能卡死或读到零值

context.WithTimeout 和 time.After 的隐藏开销

time.After 内部启动一个 goroutine 管理定时器，高频调用（如每毫秒一次）会快速堆积 goroutine；context.WithTimeout 同样依赖底层 timer，但更可控。

• 高频超时场景，复用 time.Timer：

  timer := time.NewTimer(timeout)
  ...
  timer.Reset(timeout) // 重用，不新建
  defer timer.Stop()

• HTTP handler 中必须用 req.Context()，而非自己 new context；中间件注入 deadline 后，下游 DB/HTTP client 要显式支持该 context
• 数据库查询超时不能只靠 context，PostgreSQL 需配 pgx.ConnConfig.RuntimeParams["statement_timeout"] = "5000"，MySQL 用 SET SESSION MAX_EXECUTION_TIME=5000

sync.Pool 在高频对象分配中的真实收益

频繁 make([]byte, n) 或构造小结构体（如 http.Header）是 GC 压力主因。sync.Pool 能显著降低分配频次，但要注意生命周期管理。

• Pool 对象不能含指针到长生命周期数据（如全局 map），否则阻止 GC
• Put 前清空敏感字段（如 token、password），避免下次 Get 时残留数据
• 测试时关掉 GC（GODEBUG=gctrace=1）对比 allocs/op，比压测 QPS 更早发现问题
• 示例：复用 JSON 解析缓冲

  var jsonBufPool = sync.Pool{
      New: func() interface{} {
          return make([]byte, 0, 4096)
      },
  }
  buf := jsonBufPool.Get().([]byte)
  buf = buf[:0]
  // use buf for json.Unmarshal
  jsonBufPool.Put(buf)

实际压测中，goroutine 泄漏和 channel 同步开销往往掩盖了算法层面的优化空间；先确保每个请求生命周期内 goroutine 数稳定、channel 不阻塞、context 传递到底层驱动，再谈锁粒度或零拷贝。