Activator.CreateInstance在高并发下变慢，因其依赖反射导致元数据查找、构造函数解析等操作争抢缓存锁，且存在JIT检查、装箱、GC压力等开销；推荐用Expression Tree或IL Emit预编译委托，或重构为泛型工厂、对象池等静态方案。

Activator.CreateInstance 为什么在高并发下变慢

Activator.CreateInstance 内部依赖反射，每次调用都会触发类型元数据查找、构造函数解析、参数绑定和 JIT 编译路径检查。在高并发场景下，这些操作会争抢 AppDomain 级别的反射缓存锁（尤其在 .NET Framework 中），导致线程阻塞；.NET Core/.NET 5+ 虽优化了部分缓存，但动态构造仍无法绕过 RuntimeType 解析开销。

典型现象包括：CPU 使用率不高但吞吐骤降、GC 压力上升（大量临时 object[] 参数数组）、StackOverflowException（间接由深度嵌套反射调用引发）。

• 构造无参类型时，Activator.CreateInstance(typeof(T)) 比直接 new T() 慢 5–10 倍
• 带参数构造（尤其是值类型或泛型参数）会额外触发装箱和委托绑定，性能差距扩大至 20 倍以上
• 若类型含自定义 ParameterizedConstructor 或依赖 DI 容器注入，Activator.CreateInstance 完全不适用

用 Expression Tree 预编译构造函数委托

核心思路是把“构造逻辑”提前编译为强类型的 Func 或 Func，避免每次调用都走反射路径。适用于已知类型且构造逻辑固定（如工厂模式中创建 DTO 或命令对象）的场景。

关键点：

• 首次编译有开销，必须缓存生成的委托（例如用 ConcurrentDictionary）
• 对泛型类型需按闭合类型（如 List）单独编译，不能复用开放泛型（List）
• 不支持 internal 或 private 构造函数（除非设置 BindingFlags.NonPublic，但会削弱安全性）

private static readonly ConcurrentDictionary _ctorCache = new();

public static T CreateInstanceFast() where T : new()
{
    var type = typeof(T);
    return ((Func)_ctorCache.GetOrAdd(type, t =>
    {
        var ctor = t.GetConstructor(Type.EmptyTypes);
        var lambda = Expression.Lambda>(Expression.New(ctor));
        return lambda.Compile();
    }))();
}

用 IL Emit 手写构造逻辑（.NET 5+ 推荐）

比 Expression Tree 更底层、更高效，适合对延迟极度敏感的场景（如高频消息反序列化）。.NET 5+ 的 DynamicMethod + ILGenerator 可生成与手写 new 几乎等效的代码，且无需 JIT 额外优化。

注意：

• 必须处理所有构造函数重载，包括带 ref、out 参数的情况（实际极少用）
• 无法跨 Assembly 访问 internal 类型，除非调用方 Assembly 声明了 [InternalsVisibleTo]
• 调试困难，错误通常表现为 VerificationException 或运行时崩溃

private static readonly ConcurrentDictionary _ilCtorCache = new();

public static T CreateInstanceIl() where T : new()
{
    var type = typeof(T);
    return ((Func)_ilCtorCache.GetOrAdd(type, t =>
    {
        var dm = new DynamicMethod($"Ctor_{t.Name}", t, Type.EmptyTypes, t);
        var il = dm.GetILGenerator();
        il.Emit(OpCodes.Newobj, t.GetConstructor(Type.EmptyTypes));
        il.Emit(OpCodes.Ret);
        return dm.CreateDelegate(typeof(Func));
    }))();
}

更现实的选择：重构代码避开动态创建

绝大多数高并发瓶颈其实不在构造本身，而在“为何需要动态类型创建”。真正稳定的方案往往是放弃通用性，换回明确契约。

常见替代路径：

• 用泛型工厂接口：IFactory where T : class, new()，让调用方传入类型约束而非 Type
• 预热阶段批量创建对象池（如 ObjectPool），避免运行时分配压力
• 序列化场景直接用 System.Text.Json 的 JsonSerializerOptions.TypeInfoResolver 注册静态 JsonTypeInfo，跳过反射构造
• DI 场景统一走 IServiceProvider.GetService()，而非手动 Activator.CreateInstance 模拟容器行为

硬上反射优化容易陷入“越优化越复杂”的陷阱——尤其当类型生命周期短、构造逻辑简单时，缓存委托带来的内存占用和 GC 压力可能反而抵消性能收益。

https://www.php.cn/faq/2015023.html