对象池需谨慎使用：仅当对象生命周期集中、体积大且逃逸分析失效时才适用；优先线程局部池，严格遵循Get–Reset–Use–Recycle流程，通过GC监控验证效果。
对象池不是“一加就灵”的银弹，用对了能大幅降低 GC 频次和停顿，用错了反而让 Young GC 更频繁、老年代更快填满，甚至引发对象泄漏或脏数据。关键不在“池化”，而在“是否真该池化”以及“是否真的复用成功”。
先判断：这对象到底适不适合进池
别一见高频创建就上池。真正受益的对象需同时满足：
-
生命周期可预测且集中：比如一个 HTTP 请求内反复构造的
JsonSerializerOptions（不可变、new 成本极低）就不适合；而连接生命周期内的Packet或 IO 线程中每请求一次的ByteBuf就很合适 -
单个对象体积较大：明显超过 TLAB 默认大小（Java 约 256KB）、或 Go 中
make([]byte, 0, 4096)这类预分配大缓冲，否则绕过 JVM 的 TLAB 分配和逃逸分析反而更慢 -
已确认逃逸分析失效：用
-XX:+PrintEscapeAnalysis或 JFR 查看是否大量出现Allocation outside TLAB；Go 中可通过go build -gcflags="-m"观察是否逃逸到堆
选对池类型：线程局部优先，慎用共享池
高并发下锁是瓶颈，共享池（如 Apache Commons Pool）的 synchronized 或 ReentrantLock 容易成为热点。更优解是线程隔离：
-
Java：用
ThreadLocal<stack>></stack>自建零竞争栈，或直接用 NettyRecycler（它本质就是每个 EventLoop 线程维护自己的栈） -
C#：优先用
AsyncLocal<objectpool>></objectpool>按逻辑上下文分池，避免所有线程争抢同一ConcurrentStack -
Go：
sync.Pool天然按 P（处理器）分本地缓存，无需额外隔离；但注意它不跨 P 共享，短任务中复用率可能趋近于 0
用对流程：Get–Reset–Use–Recycle/Put 必须闭环
漏掉任一环，池就形同虚设：
-
Get 后必须 Reset：池返回的对象不是新实例，可能残留旧 ID、时间戳、切片内容或 map 引用。
bytes.Buffer要调Reset()，自定义结构体要清字段、截断 slice（s = s[:0]）、清空 map（不用o.Cache = map[string]int{}，而用mapclear(o.Cache)） -
Recycle/Put 前确保无外部引用：不能在
defer里放Put后又启动 goroutine 写该对象；Netty 中严禁 IO 线程取对象、业务线程处理完再回收——必须同线程成对调用 -
New 函数只兜底，不初始化：它仅在池空时触发一次，不是每次 Get 的钩子。必须返回全新对象（
&MyObj{Data: make([]byte, 0, 128)}），禁用全局变量或复用底层数组
验证效果：别信代码，要看 GC 数据
写了池不等于压低了 GC。真实效果需用工具验证：
-
Java：用 JFR 或
jstat -gc对比 Young GC 次数、耗时、晋升量；重点关注GC pause time和old gen usage trend -
Go：用
go tool pprof查看allocs和heap，对比开启前后对象分配总量、GC 周期间隔、STW 时间 - 共性红线：若发现老年代使用率快速上升、Full GC 频次增加，大概率是池中闲置对象长期存活并晋升；此时应检查对象生命周期是否失控，或考虑降级为直接 new
