Activator.CreateInstance在对象池中不推荐直接使用，因其每次调用均绕过JIT缓存、触发类型检查与构造函数反射解析，性能开销大；应优先用Expression.Lambda编译缓存Func委托，或至少缓存ConstructorInfo。
为什么 Activator.CreateInstance 在对象池里不推荐直接用
因为每次调用都绕过 JIT 缓存、触发类型检查和构造函数反射解析，性能开销大，尤其在高频复用场景下会明显拖慢吞吐。对象池本意是省掉分配和 GC，结果被反射反向拖累。
- 优先用
Expression.Lambda编译一次、缓存委托，比如Func<t></t>工厂，后续调用接近原生构造速度 - 若必须用反射，至少把
ConstructorInfo缓存到静态字典里，键为typeof(T)，避免重复查找 - 注意：带参数的构造函数要额外处理参数类型匹配，
Activator.CreateInstance(Type, object[])容易因装箱/隐式转换失败抛ArgumentException
如何让一个池子安全支持 IDisposable 类型
不是所有对象都适合放池里——如果类型内部持有非托管资源或要求严格生命周期（比如数据库连接、文件句柄），强行复用可能引发状态污染或资源泄漏。
- 池子在
Return(T item)时，应先检查item is IDisposable disposable，然后调用disposable.Dispose()，但仅限于“可安全重置”的类型 - 更稳妥的做法是：要求池使用者显式提供
Action<t> resetAction</t>，比如对MemoryStream调用.SetLength(0)，而不是依赖Dispose - 切忌在
Get()返回前自动调用Reset()—— 有些类型 reset 逻辑昂贵（如清空大数组），应由业务侧按需触发
ConcurrentBag<t></t> 作为底层容器有哪些隐藏代价
它线程本地栈的设计确实减少锁争用，但代价是内存占用不可控、GC 压力大，且遍历时顺序完全不确定，不适合需要 LRU 或超时淘汰的池。
- 高频短生命周期对象（如网络包缓冲区）用
ConcurrentBag没问题；但若单个对象生命周期较长（>100ms），建议换成带计数的ConcurrentQueue<t></t>+ 弱引用缓存 -
ConcurrentBag的TryTake可能返回 null 即使池非空——它只查本地栈，不跨线程合并，导致“假空”现象 - 不要依赖
Count属性做监控：它是快照值，多线程下既不准又慢，改用原子整数统计已借出/归还数量
泛型约束怎么写才能兼顾类型安全和反射灵活性
不能只写 where T : class，否则无法实例化；也不能放开到 new()，因为值类型池意义不大，且 new T() 无法处理有参构造。
- 推荐双泛型参数设计：
ObjectPool<t tfactory> where TFactory : IObjectFactory<t></t></t>，把创建逻辑交给实现类，反射只发生在工厂初始化阶段 - 若坚持单泛型，用
where T : notnull+ 运行时检查构造函数存在性，比new()约束更准，能捕获struct和无参class的差异 - 反射获取构造函数时，务必用
BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance，否则私有构造器（如 singleton 辅助类）会被漏掉
真正麻烦的是跨 Assembly 的类型——Assembly.LoadFrom 后的类型，其构造器 DeclaringType 可能为 null，这时得 fallback 到 Type.GetConstructors() 全量扫描，别省这一步。
