17370845950

goroutine泄漏比内存泄漏更难发现，因持续创建不退出的goroutine会堆积栈、调度元数据及闭包变量；典型场景包括未关闭channel的for range读取、HTTP handler中无超时控制的goroutine；应通过runtime.NumGoroutine()监控、pprof对比分析阻塞状态，并强制所有异步goroutine绑定context.Context。

goroutine 泄漏比内存泄漏更难发现

Go 程序里内存暴涨，十有八九不是 make([]byte, 1e9) 这种显式分配，而是 goroutine 持续创建却不退出，附带的栈（默认 2KB）、调度元数据、可能持有的闭包变量一起堆积。典型场景是：用 for range 读 channel 却没关 channel，或 HTTP handler 启动 goroutine 但没做超时/取消控制。

• 用 runtime.NumGoroutine() 在关键路径打点，上线前加监控告警阈值（比如 >5000）
• pprof 查泄漏：启动时访问 /debug/pprof/goroutine?debug=2，对比压测前后堆栈，重点关注阻塞在 select{}、chan receive、time.Sleep 的 goroutine
• 所有异步 goroutine 必须绑定 context.Context，并在入口处用 select { case 响应取消

sync.Pool 不是万能缓存，滥用反而增加 GC 压力

sync.Pool 适合复用「临时、短生命周期、构造开销大」的对象，比如 bytes.Buffer、json.Decoder、自定义结构体。但它不解决逃逸问题，也不保证对象一定被复用——GC 会定期清空整个 Pool，且每个 P（逻辑处理器）独占一个子池，跨 P 获取要加锁。

• 不要放含指针字段过多的对象（如大 map），Pool 清空时不会触发其 finalize，可能造成内存滞留
• 必须实现 New 字段：否则 Get 返回 nil，容易 panic；且 New 创建的对象不能依赖外部状态（比如从 config 读值）
• 避免在热循环里无节制 Put：Put 是无锁的，但大量 Put 会导致 Pool 子池底层数组频繁扩容，间接加剧内存碎片

var bufferPool = sync.Pool{
    New: func() interface{} {
        return new(bytes.Buffer)
    },
}
// ✅ 正确用
法：用完立刻 Put，且确保不会被后续代码继续引用
buf := bufferPool.Get().(*bytes.Buffer)
buf.Reset() // 必须重置，因为 Pool 不保证对象干净
// ... use buf
bufferPool.Put(buf)

channel 缓冲区大小不是越大越好，要匹配消费速率

无缓冲 channel（make(chan int)）要求发送和接收严格同步，适合信号通知；带缓冲 channel（make(chan int, N)）本质是环形队列，底层数组会逃逸到堆上。如果 N 设得远大于实际峰值积压量，就白白占用内存，还可能掩盖下游处理慢的问题。

• 用 pprof heap 查看 runtime.chansend 和 runtime.chanrecv 占用，确认是否 channel 底层数组成了大头
• 生产环境建议设为「平均单次批量处理量 × 2～3」，而非拍脑袋填 1000 或 65536
• 若消费者长期跟不上，优先优化消费逻辑或加限流（如 semaphore），而不是把 buffer 拉到 10w

map 并发读写 panic 时，sync.RWMutex 不是唯一解

直接对全局 map 做并发读写会触发 fatal error: concurrent map read and map write。虽然加 sync.RWMutex 能解决问题，但读多写少时，锁竞争仍明显。Go 1.9+ 提供了 sync.Map，它用空间换时间：读操作几乎无锁，写操作分片加锁，但代价是不支持遍历、不保持插入顺序、值类型必须是 interface{}

• sync.Map 适合「键固定、读远多于写」场景（如配置缓存、连接池 registry）；频繁增删改查的业务 map 仍推荐普通 map + RWMutex
• 别用 sync.Map.LoadOrStore 替代简单判断，它内部有原子操作开销，纯读场景用 Load 更轻量
• 如果 map 键是字符串且长度可控，考虑用 unsafe.String + map[uintptr]Value 手动哈希（高级技巧，需谨慎）

真正卡住 Go 并发内存的，往往不是单个技术点用错，而是 goroutine 生命周期管理缺失 + channel 缓冲与业务流量失配 + sync.Pool 对象未重置这三者叠加。上线前跑一次 go tool pprof -http=:8080 ./binary http://localhost:6060/debug/pprof/heap，盯着 top3 的 alloc_space，比调一百次 GC 参数更管用。