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<t></t>或
Func<object object></object>，避免每次调用都走反射路径。适用于已知类型且构造逻辑固定（如工厂模式中创建 DTO 或命令对象）的场景。
关键点：
首次编译有开销，必须缓存生成的委托（例如用ConcurrentDictionary<type object></type>） 对泛型类型需按闭合类型（如
List<int></int>）单独编译，不能复用开放泛型（
List） 不支持
internal或
private构造函数（除非设置
BindingFlags.NonPublic，但会削弱安全性）
private static readonly ConcurrentDictionary<Type, object> _ctorCache = new();
public static T CreateInstanceFast<T>() where T : new()
{
var type = typeof(T);
return ((Func<T>)_ctorCache.GetOrAdd(type, t =>
{
var ctor = t.GetConstructor(Type.EmptyTypes);
var lambda = Expression.Lambda<Func<T>>(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<Type, object> _ilCtorCache = new();
public static T CreateInstanceIl<T>() where T : new()
{
var type = typeof(T);
return ((Func<T>)_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<T>));
}))();
}
更现实的选择：重构代码避开动态创建
绝大多数高并发瓶颈其实不在构造本身，而在“为何需要动态类型创建”。真正稳定的方案往往是放弃通用性，换回明确契约。
常见替代路径：
用泛型工厂接口：IFactory<t> where T : class, new()</t>，让调用方传入类型约束而非
Type预热阶段批量创建对象池（如
ObjectPool<t></t>），避免运行时分配压力 序列化场景直接用
System.Text.Json的
JsonSerializerOptions.TypeInfoResolver注册静态
JsonTypeInfo<t></t>，跳过反射构造 DI 场景统一走
IServiceProvider.GetService<t>()</t>，而非手动
Activator.CreateInstance模拟容器行为
硬上反射优化容易陷入“越优化越复杂”的陷阱——尤其当类型生命周期短、构造逻辑简单时，缓存委托带来的内存占用和 GC 压力可能反而抵消性能收益。
