goroutine泄漏是并发性能下降的头号原因，表现为mallocs持续上涨、goroutines数卡在高位；常见于time.after轮询未改用timer.reset，以及channel读写不配对导致阻塞。
goroutine 泄漏是并发性能下降的头号原因
很多程序看似开了大量 goroutine，实际却因未正确回收导致内存持续增长、调度器过载，最终吞吐不升反降。典型表现是 runtime.ReadMemStats 中 Mallocs 持续上涨，Goroutines 数量卡在高位不下。
常见泄漏点：
- 使用
time.After在长生命周期 goroutine 中轮询（应改用time.Timer.Reset） - channel 读写不配对：发送方未关闭、接收方阻塞在
上且无超时或 select default - HTTP handler 中启 goroutine 但未绑定 request context，导致请求结束但 goroutine 仍在运行
验证方式：定期调用 debug.ReadGCStats 或通过 /debug/pprof/goroutine?debug=2 查看活跃 goroutine 堆栈。
channel 使用不当会放大锁竞争
把 channel 当作通用队列或共享状态容器用，极易引发调度器争抢。例如用无缓冲 channel 做“信号量”控制并发数，所有 goroutine 都在 ch 处排队等待发送，本质退化为串行。
立即学习“go语言免费学习笔记（深入）”；
更轻量的替代方案：
- 限流用
golang.org/x/time/rate.Limiter，它基于原子计数 + 时间滑动窗口，无 goroutine 阻塞 - 状态通知优先用
sync.Once或atomic.Bool，而非单元素 channel - 必须用 channel 传递数据时，确保容量合理：缓冲 channel 容量设为预期峰值并发数 × 平均处理延迟（单位秒），避免频繁阻塞
注意：len(ch) 不是安全的长度判断依据，仅反映当前缓冲中元素数，且无法反映接收端是否已就绪。
net/http 默认配置严重拖慢高并发场景
默认 http.Server 的 MaxConnsPerHost（0 表示不限）、IdleConnTimeout（30s）、MaxIdleConns（默认 100）等参数，在压测下极易成为瓶颈。现象是 QPS 卡在某个值后不再上升，netstat -an | grep :80 | wc -l 显示大量 TIME_WAIT 或 ESTABLISHED 连接堆积。
关键调优项：
- 设置
ReadTimeout和WriteTimeout（建议 ≤ 5s），防止慢连接长期占着 goroutine - 显式配置
MaxIdleConns≥ 预期最大并发请求数，MaxIdleConnsPerHost同理 - 缩短
IdleConnTimeout到 3–5s，加速复用连接释放 - 若用 http/2，确认
Server.TLSConfig.NextProtos包含"h2"，否则 fallback 到 http/1.1
不要依赖 http.DefaultClient——它的连接池参数全为默认值，生产环境必须自定义实例。
pprof 抓不到真实瓶颈？检查 runtime.GOMAXPROCS 和 GC 频率
即使 pprof 显示 CPU 火焰图平缓，程序仍卡顿，大概率是 GOMAXPROCS 设置过低（如固定为 1）或 GC 压力过大（gc pause 占比 > 5%）。后者常因频繁分配小对象（如循环中创建 map/slice）或未复用结构体指针引起。
实操建议：
- 启动时显式设置
runtime.GOMAXPROCS(runtime.NumCPU())，除非有明确理由限制并行度 - 用
go tool pprof -http=:8080 binary_name http://localhost:6060/debug/pprof/gc观察 GC 周期与暂停时间 - 高频路径上避免
make([]byte, n)，改用sync.Pool缓存 byte slice；map 初始化指定 size（make(map[K]V, hint)）减少扩容重哈希
真正影响并发性能的，往往不是单个函数耗时，而是调度延迟、内存分配抖动和系统调用阻塞——这些在火焰图里不明显，但会显著拉高 P99 延迟。
