ObjectPool 初始化必须传入IPooledObjectPolicy或使用工厂方法，否则对象无法复用；有状态类型需自定义策略实现Create()和Return()清空逻辑；避免短期反复创建池、异步未await导致Return失效、Return前异常或超MaximumRetained上限；高频不可变对象不宜池化；调试需验证实例ID复用并监控ObjectPool计数器。
ObjectPool 用法和初始化要点
直接上手就报 NullReferenceException 或对象没复用成功？多半是池子没正确初始化。.NET 自带的 Microsoft.Extensions.ObjectPool 不是开箱即用的“自动回收器”，它只管借还逻辑，对象生命周期完全由你控制。
关键点：必须传入 IPooledObjectPolicy<t></t> 或用工厂方法构造池，否则默认策略会直接 new 对象但不回收。
-
new DefaultObjectPool<t>(new DefaultPooledObjectPolicy<t>())</t></t>是最简写法，适合无状态、可重置的类型（比如StringBuilder） - 有状态对象（如自定义 DTO、缓存上下文）必须实现
IPooledObjectPolicy<t></t>，重点重写Create()和Return(T obj)—— 后者里要手动清空字段或调用Reset() - 别用
new DefaultObjectPoolProvider().Create(...)在短期作用域反复创建池实例，这本身就在制造 GC 压力
对象归还时最常见的“假复用”陷阱
现象：对象被 Return() 了，下次 Get() 却还是 new 出来的新实例。根本原因不是池坏了，而是 Return() 被跳过或失效了。
- 异步代码里忘了 await 就 return ——
async void或未 await 的Task方法中调用Return()，执行可能被截断 - 对象在
Return()前已发生异常（比如字段被设为 null 导致后续判空失败），策略的Return()方法抛异常，池会直接丢弃该实例 - 池设置了
MaximumRetained（通过DefaultObjectPoolProvider配置），超出上限的对象会被直接 GC，不会进池 —— 查看DefaultObjectPoolProvider.MaximumRetained默认值是 100，生产环境常需调高
性能敏感场景下的参数取舍
池不是万能加速器，用错反而更慢。真实瓶颈往往不在 new，而在对象内部状态清理或线程竞争。
- 高频短生命周期对象（如每请求新建的
JsonSerializerOptions）不适合池化 —— 它不可变，new 成本极低，池引入的线程安全开销（ConcurrentStack）反而更高 - 多线程争抢同一个池时，
DefaultObjectPool<t></t>内部用的是无锁栈，但极端高并发下仍可能退化；若发现Get()耗时抖动大，可考虑按线程/租户分池，用AsyncLocal<objectpool>></objectpool>隔离 -
IPooledObjectPolicy<t>.Return()</t>里避免任何阻塞操作（如 IO、锁、复杂计算），否则会卡住整个池的归还路径
调试池是否真起效的硬核方法
别只看内存分配数下降，要验证“同一个对象实例是否被重复使用”。GC 压力降低可能是其他优化带来的副效应。
- 给池化类型加一个唯一 ID 字段（如
public int InstanceId { get; } = Interlocked.Increment(ref _id);），在Get()和Return()时打日志，观察 ID 是否复现 - 用
dotnet-counters monitor -p <pid> --counters Microsoft.Extensions.ObjectPool</pid>实时看ObjectsOut（借出数）、ObjectsIn（归还数）、NumberOfObjectsInPool（当前池中数量）三个指标是否合理波动 - 注意：启用计数器本身有性能损耗，仅用于诊断，上线前务必关闭
真正难的不是把对象塞进池，而是确保每次 Return() 都干净、及时、不被吞掉；以及确认你池化的那个对象，确实值得池化。
