.NET表达式树编译为何阻塞？Azure应用服务遗留ASP.NET问题排查

核心结论：不是误报，阻塞确实源于DynamicMethod.CreateDelegate()的资源竞争或重复编译 #

生产环境（Azure App Service）出现阻塞的原因 #

• 沙箱环境的资源竞争
  Azure App Service运行在多租户沙箱中，CLR的JIT编译线程池资源有限。当生产环境高并发请求触发大量表达式树编译时，CreateDelegate()需要等待JIT资源，从而产生阻塞。本地环境并发量低、资源充足，因此无法复现该问题。同时，沙箱的隔离策略可能降低动态代码缓存的命中率，导致重复编译，进一步放大耗时。

• 表达式树编译未缓存
  如果代码中每次请求都重复执行Expression.Lambda(...).Compile()，没有对编译后的委托进行缓存，高并发下会频繁触发CreateDelegate()，引发资源争抢。本地请求量少，即使不缓存也不会显现性能问题。

• CLR沙箱内的安全检查开销
  .NET Framework 4.8在Azure沙箱中运行时，动态方法的创建会触发额外的安全验证逻辑，这些验证在本地环境中不存在，导致CreateDelegate()的执行时间变长。

验证与解决建议 #

• 缓存编译后的委托
  使用线程安全的缓存容器（如ConcurrentDictionary）存储编译好的委托，避免重复编译。示例代码：

  private static readonly ConcurrentDictionary<string, Delegate> _compiledDelegates = new ConcurrentDictionary<string, Delegate>();
  
  public Delegate GetCompiledLambda(Expression expression)
  {
      string key = expression.ToString(); // 或使用更可靠的哈希方式生成键值
      return _compiledDelegates.GetOrAdd(key, k => Expression.Lambda(expression).Compile());
  }
  

• 预编译表达式树
  在应用启动阶段（如Global.asax的Application_Start方法）预编译所有需要用到的表达式树，将编译后的委托存入静态变量，避免请求时的编译操作。

• 优化Azure资源配置
  如果当前App Service实例规模较小，可考虑增加实例数或升级服务计划，缓解资源竞争问题。

• 替换动态编译逻辑
  对于非必要的动态表达式树场景，改用静态方法或预定义委托，从根源上消除动态编译的性能开销。

内容的提问来源于stack exchange，提问作者Alex Avrutin