.NET 8 Entity Framework内存泄漏求助（GC无法释放内存）

核心修复手段 #

• 严格管控DbContext生命周期：每个日志文件处理流程单独创建DbContext，处理完成后立即释放，杜绝复用长期存活的上下文实例。示例代码：

using (var context = new LogDbContext())
{
    await context.LogEntries.AddRangeAsync(parsedLogs);
    await context.SaveChangesAsync();
}

• 禁用不必要的实体跟踪：对于只读查询，添加AsNoTracking()减少上下文追踪开销；若业务无修改需求，可全局配置关闭跟踪：

// 单查询禁用跟踪
var duplicateLogs = context.LogEntries.AsNoTracking()
    .Where(l => l.LogId == currentLogId)
    .ToList();

// 全局配置（仅适用于纯读或批量写入场景）
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.UseSqlServer(ConnectionString)
                  .UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);
}

• 优化批量写入逻辑：拆分大批次日志为小批量提交（比如每500条提交一次），始终使用AddRange而非循环调用Add，降低上下文对象追踪压力。
• 规范事务使用方式：使用await using声明事务对象，确保事务完成后自动释放资源，避免嵌套事务或长期持有事务引用：

await using var transaction = await context.Database.BeginTransactionAsync();
try
{
    await context.SaveChangesAsync();
    await transaction.CommitAsync();
}
catch
{
    await transaction.RollbackAsync();
    throw;
}

• 升级至最新补丁版本：.NET 8.0.2存在EF Core相关的已知内存泄漏bug，升级到8.0系列的后续稳定补丁版本可直接修复官方已确认的问题。

辅助排查工具 #

• 使用dotMemory或dotnet-counters分析内存快照，定位EF Core上下文、实体追踪对象的存活路径，确认是否存在未释放的引用。
• 启用EF Core调试日志，检查是否存在未关闭的数据库连接或事务残留：

optionsBuilder.LogTo(Console.WriteLine, LogLevel.Debug);

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