c# Expression Tree 编译成委托在高并发下的缓存和性能

Expression.Compile() 不能高频调用，因其每次均生成新动态方法、触发JIT编译并分配委托，导致CPU和内存激增；应基于语义一致的表达式指纹（含委托类型）缓存编译结果。

Expression.Compile() 为什么不能直接高频调用

每次调用 Expression.Compile() 都会生成新动态方法、触发 JIT 编译、分配委托对象，底层涉及 IL 生成和元数据注册。在高并发场景下（比如每秒数千次编译），这会快速吃掉 CPU 和内存，引发 GC 压力飙升，甚至出现 OutOfMemoryException 或显著延迟毛刺。

根本问题不是 Expression Tree 本身慢，而是重复编译毫无必要——只要表达式结构相同，编译结果就该复用。

缓存 Key 必须基于表达式语义而非引用相等

直接用 expression == other 或 expression.GetHashCode() 做缓存 key 是错的：两个逻辑等价的 Expression>（比如 x => x > 5 和 y => y > 5）引用不同、哈希也不同，但编译后行为完全一致。

正确做法是提取可比较的“表达式指纹”，常见方案有：

• 用开源库如 System.Linq.Expressions.ExpressionEqualityComparer（来自 Microsoft.CodeAnalysis）做深度结构比对
• 自定义遍历表达式树，序列化关键节点（NodeType、Constant.Value、Parameter.Name 等），忽略无关细节（如参数名差异需归一化）
• 避免使用 ToString() —— 它不保证稳定，且含调试信息（如行号）

线程安全缓存选 ConcurrentDictionary 而非 MemoryCache

MemoryCache 适合带过期策略的场景，但 Expression 编译结果是纯计算产物、永不变化，加过期反而引入无谓开销和锁竞争；而 ConcurrentDictionary 提供无锁读 + 细粒度写锁，更匹配“一次编译、永久复用”模式。

典型用法：

Moshi Chat

法国AI实验室Kyutai推出的端到端实时多模态AI语音模型，具备听、说、看的能力，不仅可以实时收听，还能进行自然对话。

下载

private static readonly ConcurrentDictionary _compiledCache 
    = new();

public static TDelegate CompileCached(Expression expression)
    where TDelegate : Delegate
{
    var key = ExpressionFingerprint.Create(expression);
    return (TDelegate)_compiledCache.GetOrAdd(key, _ => expression.Compile());
}

注意：GetOrAdd 的 valueFactory 是线程安全的，不会重复执行 Compile()，这点比手动 double-check lock 更可靠。

委托类型擦除导致泛型缓存失效

如果缓存键只依赖 Expression 结构，但忽略委托类型，会出现误共享：例如 Expression> 和 Expression

>

解决方案是把委托类型纳入缓存 key：

• Key 类型定义为 (ExpressionFingerprint, Type) 元组
• 或直接用 Expression 的 GetType() 参与哈希计算
• 不要试图“泛型委托归一化”——Func 和 Predicate 就是不同类型，必须分开缓存

缓存膨胀风险低：实际业务中同一表达式被不同委托类型引用的情况极少，且 key 是轻量结构，不是表达式树本身。

最易被忽略的一点：缓存的是委托实例，不是表达式树。一旦你修改了表达式里捕获的闭包变量（比如 int threshold = 10; Expression> e = x => x > threshold;），这个 threshold 是编译时快照，后续改 threshold 值不影响已编译委托——所以缓存安全。但如果你误把可变变量当常量用，逻辑错误不会因缓存而暴露，反而更难调试。