sync.pool仅在高频分配、短生命周期、可安全重置三者同时满足时才有效；盲目使用反而增加锁开销、脏数据和use-after-free风险，且new必须返回全新对象并避免副作用，get后须显式重置，put前须确保无引用。
sync.Pool 不是缓解小对象 GC 压力的通用解法，它只在「高频分配 + 短生命周期 + 可安全重置」这三点同时满足时才真正有效；盲目套用反而增加锁开销、脏数据风险和 use-after-free 漏洞。
什么时候该用 sync.Pool，而不是直接 make 或结构体字面量
你得先确认问题真出在小对象分配上，而不是算法或设计层面：
- 用 go tool pprof -alloc_space 查 heap profile，看是不是某类对象（如 []byte、*bytes.Buffer）占了绝大多数 allocs/op
- QPS ≥ 1k 且单请求内该对象创建 ≥ 10 次（比如 JSON 解析循环、HTTP 中间件链中反复构造上下文）
- 对象大小稳定 ≤ 8KB（超过 32KB 会绕过 mcache，Pool 基本失效）
- 对象不含外部资源（文件句柄、网络连接）、不带 finalizer、不跨 goroutine 长期持有
- 你能控制它的完整生命周期：从 Get 到 Put 之间不逃逸、不传 channel、不闭包捕获
sync.Pool.New 必须返回全新对象，且不能有副作用
这是最常 panic 的地方：
- ❌ 错误写法：var globalBuf bytes.Buffer; New: func() interface{} { return &globalBuf } → 多个 goroutine 同时读写同一内存，竞态或数据污染
- ✅ 正确写法：New: func() interface{} { return &bytes.Buffer{} } 或 New: func() interface{} { return make([]byte, 0, 1024) } → 每次调用都分配新内存
- New 函数可能在任意 goroutine 中被触发（比如 GC 后首次 Get），不能做 os.Open、http.Get 等耗时或有状态操作
- 若需预分配容量（如底层数组），必须在 New 里完成，不能靠 Get 后再 append 或 grow，否则复用失去意义
Get 后必须显式重置，Put 前必须确保无引用
sync.Pool 不会帮你清字段、不会调 Reset()、也不会检查残留数据：
- 对 *bytes.Buffer：必须调 buf.Reset()（比 Truncate(0) 更安全，会清长度并保留底层数组）
- 对 slice 字段：s.Data = s.Data[:0]，不是 s.Data = nil（后者丢弃底层数组，等于白池化）
- 对 map 字段：Go 1.21+ 可用 mapclear(m)；旧版本得 for k := range m { delete(m, k) }，不能只赋 nil
- Put 前务必确认对象已彻底脱离作用域：没发到 channel、没启动异步 goroutine、没作为返回值传出、没被闭包捕获
- 禁止无脑 defer pool.Put(x)：函数 panic 或提前 return 时 defer 不执行，对象永久泄漏；HTTP handler 中尤其危险
验证是否真有效，而不是自我安慰
别只看代码写了 Get/Put 就以为生效了：
- 观察日志是否频繁出现 runtime: mark sweep GC freed X objects, but pool swept Y → 说明刚 Put 就被 GC 扫掉，池基本空转
- 对比开启前后 go tool pprof http://localhost:6060/debug/pprof/heap?debug=1 的 allocs/op 和 GC pause 时间
- 注意：如果 profile 显示 runtime.mallocgc 占比高，优先排查是不是算法在反复分配大 slice 或嵌套结构——sync.Pool 只转移分配压力，不解决根本设计问题
真正难的不是写对 Get 和 Put，而是判断一个对象“能不能安全 Reset”：它内部有没有隐藏状态（比如未导出字段、底层指针别名、依赖 runtime 行为），这点没法靠工具静态检查，只能靠读源码、压测、看 heap profile 的对象存活链。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
