goroutine泄漏导致内存持续上涨，主因是goroutine不退出且不被gc回收；常见于未关闭channel却range、select缺default/timeout、http handler未cancel等。
goroutine 泄漏导致内存持续上涨
goroutine 不退出、不被 GC 回收，是并发程序最隐蔽的性能杀手。常见于 channel 未关闭却持续 range、select 中缺少 default 或 timeout、HTTP handler 启动 goroutine 后忘记 cancel 控制。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.NumGoroutine()定期打点，观察是否随请求量线性/阶梯式增长 - 访问
/debug/pprof/goroutine?debug=2查看所有 goroutine 的堆栈，重点关注阻塞在chan receive、semacquire、netpoll的调用链 - 对长期运行的 goroutine，务必绑定
context.Context，并在 handler 入口用ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second) - 避免在循环中无节制启动 goroutine，例如
for _, item := range items { go process(item) }—— 应改用带缓冲的 worker pool
channel 阻塞引发调度延迟
无缓冲 channel 的发送/接收必须双方同时就绪，否则会挂起 goroutine；有缓冲 channel 若缓冲区满或空，同样触发阻塞。这类阻塞不会报错，但会让 P 被占用、M 切换开销上升，尤其在高并发 I/O 场景下放大延迟。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
go tool pprof http://localhost:6060/debug/pprof/block查 block profile，重点看chan receive和chan send占比 - 优先考虑非阻塞操作：用
select { case ch 替代直接 <code>ch ，防止背压堆积 - 缓冲 channel 大小不是越大越好：过大会掩盖设计缺陷，还浪费内存；建议按预期峰值并发 × 平均处理耗时估算，例如 100 QPS × 0.2s = 20，再乘 2 倍安全系数设为 40
- 慎用全局 channel（如日志通道），它容易成为争用热点；可考虑每个 worker 自持 channel + 批量 flush
sync.Mutex 在高竞争场景下拖慢吞吐
当多个 goroutine 频繁争抢同一把锁，Lock() 会陷入自旋 + 操作系统信号量等待，导致大量 goroutine 排队、P 资源闲置。pprof 的 mutex profile 能直接暴露热点锁和平均等待时间。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 运行
go tool pprof http://localhost:6060/debug/pprof/mutex，查看sync.(*Mutex).Lock的 flat/ms 占比和 contention - 缩小临界区：只锁真正共享写的部分，读操作尽量用
sync.RWMutex或无锁结构（如atomic.Value） - 用分片锁替代全局锁：比如将一个大 map 拆成 32 个子 map + 32 把锁，key 哈希后取模选择锁，降低碰撞概率
- 确认是否真需要互斥：某些计数场景可用
atomic.AddInt64(&counter, 1)，比 Mutex 快一个数量级
GC 压力来自高频小对象分配
并发代码常伴随大量临时对象创建：闭包捕获变量、fmt.Sprintf、strings.ReplaceAll、JSON 序列化等。这些对象虽生命周期短，但若每秒分配数百万次，会显著抬高 GC 频率（godebug gc -s 可见 pause 时间飙升）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
go tool pprof http://localhost:6060/debug/pprof/heap查 alloc_objects，结合 source 看哪行代码分配最多 - 复用对象：用
sync.Pool缓存 struct 指针、bytes.Buffer、JSON encoder/decoder；注意 Pool 中对象无序，不能依赖初始化状态 - 避免字符串拼接：用
strings.Builder替代str += "a" + "b"，前者零分配（预估容量够时） - 检查第三方库：某些 HTTP client 默认启用 gzip、JSON 库默认使用反射——关掉不用的特性能省下可观分配
实际调优时，block 和 mutex profile 往往比 cpu profile 更早暴露瓶颈；而 goroutine 数量和 GC pause 时间是两个必须盯死的基础指标。
