sync.Pool 的 Get() 经常返回 nil 是正常行为，因 GC 会清空未引用对象、goroutine 迁移可能导致本地池遗弃；New 函数需线程安全且每次返回新实例；对象按 P 分片为避免锁竞争，但跨 P 调度会触发慢路径；Put 前须 Reset 否则复用“脏对象”；仅高频、短生命周期、小对象适用，大对象或低频使用反而拖慢性能。
sync.Pool 的 Get() 为什么经常返回 nil？
因为 sync.Pool 不保证对象存活——它不是缓存，也不是对象池意义上的“稳定容器”。GC 触发时，所有未被引用的池中对象会被批量清空；而 goroutine 迁移、P 被抢占，也可能导致本地池被遗弃。所以 Get() 返回 nil 是正常行为，不是 bug。
- 每次 GC 后，每个 P 的 victim cache 全清，global 链表只保留最近一次
Put()的对象 -
New函数只在池为空时兜底调用，且可能被多个 goroutine 并发触发，必须线程安全、无副作用 - 不要在
New里复用全局变量（如&globalBuf），否则多个 goroutine 会并发读写同一实例，引发 panic - 正确做法：每次返回全新实例，例如
return &bytes.Buffer{}或return &MyStruct{data: make([]byte, 0, 1024)}
为什么对象要按 P 分片？跨 P 获取代价有多大？
Go 运行时为每个逻辑处理器（P）维护独立的本地池，目的是避免锁竞争。这是 sync.Pool 高性能的核心设计，但也带来调度敏感性。
- goroutine 在固定 P 上执行时，
Get()/Put()走 fast path，几乎无开销 - 若 goroutine 被调度到另一个 P（比如系统调用返回、抢占），再调用
Get()就会触发 slow path：先查本地池，再查 shared 队列，最后才调New，延迟明显上升 - 高并发下若 goroutine 频繁迁移（如大量阻塞 IO），本地池利用率下降，复用率暴跌，甚至不如直接 new
- 压测时观察
runtime.mallocgc占比和sync.Pool相关 allocs profile，比看“用了没”更真实
Put 前不 Reset 会出什么问题？
Pool 不做任何状态清理：Put() 只是把指针挂进链表，底层数组、map、切片长度、字段值全保留。下次 Get() 拿到的就是“脏对象”。
- bytes.Buffer 复用后不
Reset()→ 上次写入内容还在，WriteString()会追加而非覆盖，输出错乱 - 结构体里有
map[string]int字段，没清空 → 下次使用时 key 冲突、计数异常，甚至 panic - 切片字段只做
s = s[:0]，不置nil→ 底层数组持续占用，阻碍 GC 回收大内存块 - 推荐统一提供
Reset()方法，例如：func (b *Buffer) Reset() { b.data = b.data[:0] }
哪些场景真能省内存，哪些反而拖慢性能？
sync.Pool 只对「高频分配 + 短生命周期 + 小对象」有效。它不是银弹，用错比不用更糟。
立即学习“go语言免费学习笔记（深入）”；
- 适合：HTTP handler 中的
*bytes.Buffer、json.Decoder、预分配[]byte缓冲（make([]byte, 0, 1024)） - 不适合：含外部资源的对象（
net.Conn、未 close 的os.File）、大对象（>1KB 结构体）、带锁或上下文状态的实例 - 低频使用（比如每秒几次）放入 Pool，反而增加 per-P 管理开销和 GC 扫描负担
- 长期持有池中对象（如存在全局 map 或 channel 中）→ 阻碍 victim 清理，导致内存滞留，GC 效率下降
最常被忽略的一点：你 Put 进去的对象，可能下一毫秒就被 runtime 彻底丢弃；别指望它保活，也别在 Put 里塞 Close/Flush 逻辑——那些代码大概率根本不会执行。
