sync.pool复用率无法直接测量，因其不暴露统计接口；需通过外部埋点（如标记对象来源并原子计数）、控制gc与p数量、避免逃逸等方式间接观测。
为什么 sync.Pool 的复用率不能直接测
Go 的 sync.Pool 本身不暴露任何统计接口，也没有「命中次数」「丢弃次数」这类指标。你写 pool.Get() 和 pool.Put()，它只管尽力复用，但不会告诉你这次是新分配还是从池里拿的。所以想靠 Pool 自身 API 测复用率，行不通。
常见错误是试图在 New 函数里加计数器，以为“调用一次 New 就代表一次未命中”——这不对。sync.Pool 可能在 GC 前清空整个池，也可能在高并发下因本地池（per-P）竞争而 fallback 到全局池再 fallback 到 New，New 被调用的次数 ≠ 实际未命中次数。
实操建议：
- 复用率必须靠外部观测：在
New和Get中埋点，但要区分「首次 Get」和「非首次 Get」 - 基准测试中禁用 GC 干扰（
runtime.GC()手动触发 +testing.B.ReportAllocs()配合看分配量） - 避免在
Benchmark函数里直接计数——它会被多次调用，计数器需定义在函数外或用sync/atomic
用原子计数器模拟「Get 来源」判断
核心思路：让每次 Get 返回的对象带一个来源标记，再用原子变量分别统计「来自池」和「来自 New」的次数。这不是测 Pool 内部行为，而是测你代码里实际发生了什么。
立即学习“go语言免费学习笔记（深入）”；
典型场景是测试一个对象池化结构体的使用路径，比如 type Buf struct{ data []byte }。
实操建议：
- 在结构体里加一个
fromPool bool字段，New返回时设为false，Put前设为true -
Get后检查该字段，用atomic.AddInt64(&hit, 1)或atomic.AddInt64(&miss, 1)累加 - 注意：这个标记仅用于测试，生产环境别留着，它破坏了零值语义且影响缓存行对齐
- 示例片段：
var hit, miss int64 pool := &sync.Pool{ New: func() interface{} { atomic.AddInt64(&miss, 1) return &Buf{fromPool: false} }, } // 在 Get 后： b := pool.Get().(*Buf) if b.fromPool { atomic.AddInt64(&hit, 1) } else { atomic.AddInt64(&miss, 1) } b.fromPool = true // Put 前重置
基准测试中 GC 和调度对复用率的隐性干扰
Go 基准测试默认不控制 GC 频率，而 sync.Pool 的生命周期强依赖 GC 周期：每次 GC 会清空所有未被引用的池对象。如果你的 Benchmark 单次迭代时间短、分配少，可能压根没触发 GC；如果迭代多、时间长，又可能被多次 GC 洗掉池内容——导致复用率忽高忽低，不可比。
另一个干扰是 P（processor）数量变化。Go 运行时会动态增减 P，而每个 P 有独立本地池。当 Benchmark 并发度高但 GOMAXPROCS 未固定，本地池切换会导致 Put 的对象进不了下次 Get 的本地池，被迫走全局池甚至 New。
实操建议：
- 测试前固定
runtime.GOMAXPROCS(1)或显式设为常量，避免 P 动态伸缩 - 在
Benchmark开头手动触发一次 GC（runtime.GC()），并在循环前后各调一次，确保池初始为空且最终状态可控 - 用
b.ReportMetric(float64(hit)/float64(hit+miss), "hit-ratio")输出比率，比单纯看 allocs 更反映复用意图 - 别信单次运行结果——跑 5–10 轮取中位数，因为 GC 时间抖动大
比复用率更关键的是「对象是否真的被复用」
很多人盯着 hit-ratio 数字，却忽略了一个事实：即使 Get 拿到了池里的对象，如果后续代码立刻 make 新底层数组、重写字段、或触发逃逸，那这次「复用」就是假的——内存分配照旧发生，只是对象头复用了。
比如 Buf 里有个 data []byte，如果每次 Get 后都做 b.data = make([]byte, 1024)，那池里原来的 data 就被丢弃了，底层依然在分配。
实操建议：
- 用
go tool compile -gcflags="-m"确认关键结构体是否逃逸；池化对象应尽量避免指针字段或动态分配 - 复用对象前先
Reset()，而不是覆盖字段——尤其要注意 slice 的cap是否足够，不够就扩容但别总make - 观察
testing.B.N增大时，BytesPerOp是否稳定下降；如果 allocs 减少了但BytesPerOp不变，说明底层数组还在反复分配
复用率数字容易造出来，但对象生命周期是否真正收敛，得看分配行为本身。这点在压测时最容易被忽略。
