C#中如何修复可枚举Lambda的闭包内存分配问题

你提出的「使用Where等方法传入外部参数就必然生成闭包、只能改用循环修复」的判断不完全正确，闭包分配的优化有多种可落地方案，循环只是其中性能最稳妥的一种，并非唯一选择。

• 当Lambda表达式引用了方法栈上的局部变量、传入参数（而非Lambda自身参数、全局静态值、无状态常量）时，编译器会自动生成<c_DisplayClassxx>类型包装被捕获的变量，这部分会产生堆分配。
• 无任何捕获的Lambda在.NET Core 2.1+版本中会被运行时自动缓存，不会产生重复的委托分配，也不会生成DisplayClass。
• 只要将Lambda转换为Func<>/Action<>委托类型传入LINQ方法，哪怕没有捕获变量，在旧版.NET Framework中也会每次新建委托实例产生分配。

按推荐优先级排序：

1. 热路径直接用for/foreach手动过滤 #

这是零分配、最易维护、无任何坑的方案，不存在“放弃LINQ很low”的问题，性能敏感的高频调用路径优先选这个写法。
针对你给出的示例代码，改造后逻辑如下：

public IList<RequirementMappingRule> FindItems(ProductFilterMap productMapItem, 
    RuleProviderContext context)
{
    var financialCompanyCode = productMapItem.Product.Product.FinancialCompanyCode;
    var parentRiskCode = productMapItem.ParentRiskCode;
    var riskCode = productMapItem.Risk.Risk.Code;
    var ruleCandidates = new List<RequirementMappingRule>();
    
    foreach (var r in Items)
    {
        if ((r.CompanyCode == financialCompanyCode || r.CompanyCode == "*")
            && r.ParentRiskCode == parentRiskCode
            && (string.IsNullOrWhiteSpace(r.RiskCode) || r.RiskCode == riskCode)
            && r.IsValidByRiskValue(productMapItem, context))
        {
            ruleCandidates.Add(r);
        }
    }
     
    // 后续逻辑...
}

这段代码不会生成任何DisplayClass类型，也没有委托实例分配，GC压力为0。

2. 值类型谓词方案（保留LINQ写法，零分配） #

如果你想保留链式调用的LINQ风格，可以自定义值类型的谓词结构体，利用泛型方法的特性避免装箱和闭包分配。
首先定义过滤用的只读结构体，把所有需要的参数存为结构体字段：

using System.Runtime.CompilerServices;

private readonly struct RuleMatchPredicate
{
    private readonly string _financialCompanyCode;
    private readonly string _parentRiskCode;
    private readonly string _riskCode;
    private readonly ProductFilterMap _productMapItem;
    private readonly RuleProviderContext _context;

    public RuleMatchPredicate(string financialCompanyCode, string parentRiskCode, string riskCode, ProductFilterMap productMapItem, RuleProviderContext context)
    {
        _financialCompanyCode = financialCompanyCode;
        _parentRiskCode = parentRiskCode;
        _riskCode = riskCode;
        _productMapItem = productMapItem;
        _context = context;
    }

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public bool Invoke(RequirementMappingRule r)
    {
        return (r.CompanyCode == _financialCompanyCode || r.CompanyCode == "*")
               && r.ParentRiskCode == _parentRiskCode
               && (string.IsNullOrWhiteSpace(r.RiskCode) || r.RiskCode == _riskCode)
               && r.IsValidByRiskValue(_productMapItem, _context);
    }
}

再配合一个简单的泛型Where扩展方法，避免Func委托带来的分配：

public static class EnumerableExtensions
{
    public static List<TSource> WhereZeroAlloc<TSource, TPredicate>(this IEnumerable<TSource> source, TPredicate predicate)
        where TPredicate : struct
    {
        var result = new List<TSource>();
        foreach (var item in source)
        {
            if (predicate.Invoke(item))
            {
                result.Add(item);
            }
        }
        return result;
    }
}

使用时直接传入结构体实例即可，整个过程没有闭包、没有委托装箱、没有DisplayClass生成，性能和手动写循环几乎一致。

3. 委托缓存方案（适合固定参数场景） #

如果你的过滤参数是固定的几个枚举值、常量，可以把对应的Func委托缓存为静态字段，避免每次调用都新建委托和闭包，不过这个方案灵活性差，只适合参数固定的场景。

不要盲目优化所有闭包：如果这段方法不在请求热路径、每秒调用次数不足百次，闭包带来的几十字节分配完全可以被GC高效回收，不会造成可感知的性能问题。盲目把所有LINQ改成循环、或者写大量值类型谓词，反而会大幅降低代码可读性，得不偿失。只有在通过Profiler确认闭包分配确实是GC压力瓶颈时，再做针对性优化。

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