goroutine 启动开销不大，但滥用“一请求一goroutine”会加剧gc压力和调度负担；应优先用channel+worker pool替代；gomaxprocs调高反增上下文切换；channel缓冲区需按场景设定，非越大越好。
goroutine 启动开销大？别盲目复用 runtime.GOMAXPROCS
Go 默认为每个 goroutine 分配 2KB 栈空间（1.14+ 可动态收缩），但频繁创建/销毁仍带来 GC 压力和调度开销。关键不是减少 goroutine 数量，而是避免“一请求一 goroutine”式滥用。
- HTTP handler 中用
go f()启动短命 goroutine 时，优先考虑改用 channel + worker pool，尤其当并发量 >1000 时 -
runtime.GOMAXPROCS控制的是 OS 线程数，不是 goroutine 数；调高它不会降低内存，反而可能加剧上下文切换——除非你有大量阻塞系统调用 - 用
pprof.Lookup("goroutine").WriteTo(w, 1)定期采样，重点关注状态为runnable或waiting但长期不退出的 goroutine
channel 缓冲区设多大？看场景，不是越大越好
无缓冲 channel 会强制 goroutine 同步等待，容易造成堆积；但过大缓冲区（如 make(chan int, 10000)）会让数据滞留在内存中，延迟 GC 回收。
- 生产者消费者模型中，缓冲区大小应 ≈ 单次批处理量 × 1.5，例如批量写日志：每批 100 条 → 缓冲设 150
- 纯信号通知场景（如
done chan struct{}）必须用无缓冲，避免漏通知 - 用
len(ch)监控 channel 积压，配合超时 select：select { case ch
defer 在循环里导致内存泄漏？是的，且很难察觉
每个 defer 语句会在当前 goroutine 的 defer 链表中分配一个 _defer 结构体（约 32 字节），循环中写 for _, v := range data { defer close(v.ch) } 会累积大量未执行的 defer。
- 把 defer 提到循环外，或改用显式清理：
for _, v := range data { close(v.ch) } - 若必须延迟执行，改用函数值缓存：
var cleanups []func(); for _, v := range data { cleanups = append(cleanups, func() { close(v.ch) }) }; for _, f := range cleanups { f() } - 用
go tool compile -gcflags="-m" main.go检查是否出现... moved to heap—— defer 变量逃逸到堆是典型征兆
sync.Pool 不是万能的，用错反而增加 GC 压力
sync.Pool 适合复用临时对象（如 []byte、bytes.Buffer），但对象生命周期必须严格可控。误用会导致对象在 Pool 中滞留过久，占用内存却不被复用。
立即学习“go语言免费学习笔记（深入）”；
- Pool 的
Get不保证返回零值，每次使用前必须手动重置：b := bufPool.Get().(*bytes.Buffer); b.Reset() - 不要把含指针字段的大结构体放进 Pool，GC 无法扫描 Pool 中的对象，易造成隐性内存泄漏
- 高频小对象（如
int、string）没必要进 Pool —— 分配成本远低于 Pool 查找开销
实际调优时最常被忽略的一点：goroutine 的栈增长是按需触发的，但一旦涨到 1MB 就很难缩回去。如果发现 runtime.ReadMemStats 中 StackInuse 持续高位，大概率是有 goroutine 在做深度递归或持有大局部变量，而不是并发数本身的问题。
