Entity Framework 6重建Context后旧对象驻留内存导致内存溢出问题咨询

Dispose()方法仅负责释放Context关联的数据库连接等非托管资源，托管堆上的Context实例需要等GC检测到没有任何根引用时才会被回收。你遇到的旧Context实例残留，要么是仍有代码持有该实例的引用，要么是GC尚未触发回收。另外你的代码存在计数变量名错误，会导致重建Context的逻辑完全不生效，这也是内存溢出的核心诱因之一。

• 改用using块管理Context生命周期。将每批次1万条的处理逻辑完全包裹在独立的using作用域内，出作用域后Context变量自动脱离根引用，GC可正常回收所有关联的实体、跟踪包装类等资源，避免手动Dispose的遗漏问题。
• 为查询添加AsNoTracking()减少跟踪开销。默认情况下EF查询返回的实体会被StateManager跟踪缓存，哪怕关闭AutoDetectChangesEnabled也不例外。查询时添加AsNoTracking()，仅在需要更新时手动Attach实体，可大幅降低单批次内存占用。
• 优化单条查询逻辑为批量查询。当前每条记录都单独发起数据库查询，250万条会产生250万次SQL请求，性能极差且会产生大量临时对象。可以每批次先收集当前1万条的匹配键，一次性从数据库查询所有匹配记录存入字典，再在内存中匹配判断新增/更新，既提升性能也减少跟踪实体数量。
• 可选：使用EF批量操作库优化写入性能。EF原生SaveChanges会为每条记录生成单独的SQL语句，1万条就会产生1万次数据库请求，可使用EntityFramework.BulkInsert、Z.EntityFramework.Extensions等库的批量插入/更新方法，将批次操作合并为单次SQL请求，性能提升10~100倍，同时进一步降低内存占用。

const int BatchSize = 10000;
var itemCount = 0;
// 用于暂存当前批次的CSV解析数据
var batchCsvItems = new List<CsvItem>();

// using块自动管理文件流释放
using (var file = new System.IO.StreamReader(filepath, System.Text.Encoding.UTF8))
{
    string line;
    while ((line = file.ReadLine()) != null)
    {
        // 解析CSV行为自定义结构，避免后续重复解析
        var csvItem = ParseLineToCsvItem(line);
        batchCsvItems.Add(csvItem);
        itemCount++;

        // 达到批次阈值则处理当前批次
        if (itemCount % BatchSize == 0)
        {
            ProcessBatch(batchCsvItems);
            batchCsvItems.Clear();
        }
    }

    // 处理最后不足1万条的剩余数据
    if (batchCsvItems.Any())
    {
        ProcessBatch(batchCsvItems);
    }
}

// 独立批次处理方法，Context完全隔离
void ProcessBatch(List<CsvItem> batchItems)
{
    // using块包裹Context，执行完自动释放所有关联资源
    using (var context = new MyDataEntities())
    {
        context.Configuration.AutoDetectChangesEnabled = false;
        
        // 批量查询当前批次所有匹配的数据库记录，仅查一次库
        var matchKeys = batchItems.Select(x => x.MatchKey).ToList();
        var existDict = context.MyTable
            .Where(f => matchKeys.Contains(f.MatchKey))
            .ToDictionary(x => x.MatchKey);

        foreach (var csvItem in batchItems)
        {
            if (existDict.TryGetValue(csvItem.MatchKey, out var existItem))
            {
                // 更新现有实体，手动Attach后标记为修改
                context.MyTable.Attach(existItem);
                existItem.MyProperty = csvItem.MyProperty;
                context.Entry(existItem).State = System.Data.Entity.EntityState.Modified;
            }
            else
            {
                // 新增实体
                var newItem = context.MyTable.Create();
                newItem.MyProperty = csvItem.MyProperty;
                // 其余字段赋值
                context.MyTable.Add(newItem);
            }
        }

        context.SaveChanges();
    }
}

// CSV行结构示例，根据实际业务修改
class CsvItem
{
    public string MatchKey { get; set; }
    public string MyProperty { get; set; }
    // 其余CSV字段
}

如果修改后仍观察到旧Context实例残留，可以在批次处理结束后手动触发GC回收验证是否为引用问题：

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

如果触发后旧Context实例消失，说明原本只是GC尚未触发回收，无需额外处理；如果仍残留，需要排查代码中是否有其他地方持有Context或者实体的引用（比如全局变量、静态变量、事件订阅等）。

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