sync.pool 对大对象有效因其复用可跳过gc标记清扫，但小对象分配快、gc成本低，加pool反增锁竞争和指针开销；new应做轻量初始化，避免昂贵操作；pool不保证跨gc周期存活，需防goroutine泄漏导致性能陡降。
为什么 sync.Pool 对大对象有用，但对小对象可能白忙活
因为 GC 压力主要来自堆上频繁分配/释放的大对象（比如 > 1KB 的 []byte、结构体切片、解析器实例），sync.Pool 能让它们在 goroutine 间“暂存复用”，跳过分配和标记清扫阶段。但小对象（如几个字段的 struct）本身分配快、GC 成本低，加一层 Pool 反而引入锁竞争和指针跳转开销，实测可能更慢。
- 典型适用场景：
json.Decoder实例、HTTP body 缓冲区（make([]byte, 0, 4096)）、Protobuf 解析器、临时bytes.Buffer - 不适用场景：单个
int、string、短生命周期的轻量 struct（如type Point struct{ X, Y int }） -
Pool.Get()不保证返回非 nil —— 必须检查并初始化；Pool.Put()不能放 panic 后的脏对象（比如含已关闭文件描述符的结构体）
sync.Pool 的 New 函数该写什么逻辑
New 是兜底工厂函数，只在 Get() 拿不到可用对象时调用。它不该做昂贵初始化（如打开文件、建连接），也不能依赖外部状态（比如从全局 map 查配置），否则会掩盖复用失效的真实原因。
- 正确写法：
New: func() interface{} { return &MyParser{buf: make([]byte, 0, 2048)} } - 错误写法：
New: func() interface{} { return newDBConnection() }（连接不该复用，且失败会卡死整个 Pool） - 注意：返回值必须是
interface{}，建议用指针避免值拷贝；如果对象含 sync.Mutex，必须在New里初始化（Mutex 零值可用，但别依赖）
goroutine 泄漏 + sync.Pool 清空导致的“对象突然变慢”
sync.Pool 在每次 GC 前会被清空，且不保证对象存活跨 GC 周期。如果你在长生命周期 goroutine（比如 HTTP handler 中启的后台协程）里 Put 了对象，又没控制好 Get/put 平衡，就可能出现：前几秒很快，GC 后大量 New 被触发，延迟陡增。
- 验证方法：开启
GODEBUG=gctrace=1，观察 GC 频次与Pool.New调用日志是否同步激增 - 缓解手段：给 Pool 加统计（原子计数器），监控 Get/Put 比例；避免在定时任务或常驻 goroutine 中无节制 Put
- 关键限制：Pool 不是内存池，不管理生命周期 —— 它只缓存“最近被同 goroutine 用过的对象”，跨 goroutine 传递后复用率断崖下跌
对比 sync.Pool 和对象池手动管理（比如 channel + slice）
手动池（如 chan *T）能精确控制生命周期、支持超时驱逐、可阻塞等待，但要自己处理并发安全、泄漏防护、初始化逻辑。而 sync.Pool 把“局部性”做到了 runtime 层，每个 P（逻辑处理器）有独立私有池，Get/Put 基本无锁，适合高吞吐、短生命周期复用。
立即学习“go语言免费学习笔记（深入）”；
- 选
sync.Pool：HTTP server 每请求复用 buffer、parser；高频小批量解码 - 选手动池：需要复用带连接状态的对象（如 DB 连接）、要求对象保活超过 GC 周期、需按优先级回收
- 性能提示：Go 1.19+ 对
sync.Pool做了私有池扩容优化，但 Put 过多仍会触发全局锁 —— 单次 Put 别塞几百个对象
真正难的是判断“这个对象到底值不值得进 Pool”：得看 p99 分配耗时、GC pause 占比、对象大小与构造成本。跑一下 go tool pprof 看 heap profile 里哪些类型占大头，比凭感觉加 Pool 可靠得多。
