数据上下文注册为瞬态，但内存使用量不断增长。我的 DI 配置有问题吗？

我在用着EF Core和...一起Postgres（可能并不重要）在一个.NET Core 3.1 控制台应用程序.

该程序使用一个共享项目（以及解决方案的其他组件），所有业务逻辑均使用简单的 CQRS 类型模式和 Mediator 来实现。

在一处，我从数据库中检索大小为 10 - 100MB 的大型对象。这种情况并不常见，因此本身不是问题。在现代硬件上只需几分之一秒的时间。 问题是，由于某种原因，这些对象在命令执行之间被缓存在数据上下文中，就像数据上下文没有被释放一样。

我不明白为什么，因为我将 DI 容器（内置标准）内的 DbContext 注册为瞬态。我的理解是，它应该在每次请求时创建一个新实例，而垃圾收集器应该处理其余的事情。

注册码是这样的：

static IServiceProvider ConfigureServiceProvider()
{
    IServiceCollection services = new ServiceCollection();
    
    DbContextOptions<MyAppDbContext> dbContextOptions = new DbContextOptionsBuilder<MyAppDbContext>()
       .UseNpgsql(Configuration.GetConnectionString("MyApp.Db"))
       .Options;
    services.AddSingleton(dbContextOptions);
    services.AddDbContext<MyAppDbContext>(options => options.UseNpgsql(Configuration.GetConnectionString("MyApp.Db"), options => options.EnableRetryOnFailure()), ServiceLifetime.Transient);
    services.AddTransient<IMyAppDbContext>(s => s.GetService<MyAppDbContext>());

    // (...)
}

然后命令以这种方式使用它：

public class RecalculateSomething : IRequest
{
    public Guid SomeId { get; set; }

    public class Handler : IRequestHandler<RecalculateSomething>
    {
        private IMyAppDbContext context;
        private readonly IMediator mediator;

        public Handler(IMyAppDbContext context, IMediator mediator)
        {
            this.context = context ?? throw new ArgumentNullException(nameof(context));
            this.mediator = mediator ?? throw new ArgumentNullException(nameof(mediator));
        }
        
        public async Task<Unit> Handle(RecalculateSomething request, CancellationToken ct)
        {       
            // (...)
        }
    }
}

有谁知道问题是什么？我在配置 DI 容器时做错了什么吗？或者其他东西，比如我在某处保存的参考资料（找不到）。解决此类问题的最佳方法是什么？

顺便说一句，我通过强制它每次从 DbContextOptions 创建一个新的 DbContext 来“修复它”，但这更多的是一种解决方法。想知道核心问题是什么。

您几乎永远不想注册DbContext。最好注册一个工厂，用它来创建一个新的工厂DbContext根据每一个要求。虽然这看起来效率低下，但该模式多年来一直在优化，并且允许您根据每个请求确定地回收资源。

来自文件 https://learn.microsoft.com/en-us/ef/core/dbcontext-configuration/

DbContext 的生命周期从创建实例时开始，到实例被释放时结束。 DbContext 实例设计用于单个工作单元。这意味着 DbContext 实例的生命周期通常很短。

该文档继续解释说您可以注入它，您正在这样做，但问题是这缺乏确定性的资源回收。最好使用工厂来保持这一点，对此进行了解释later https://learn.microsoft.com/en-us/ef/core/dbcontext-configuration/在同一份文件中

某些应用程序类型（例如 ASP.NET Core Blazor）使用依赖项注入，但不创建与所需 DbContext 生命周期一致的服务范围。即使确实存在这种对齐，应用程序也可能需要在此范围内执行多个工作单元。例如，单个 HTTP 请求中的多个工作单元。

在这些情况下，AddDbContextFactory 可用于注册用于创建 DbContext 实例的工厂。

我敢打赌，正是这种非确定性、查询的大尺寸和查询的频率的组合导致了应用程序中的一些内存压力。

您可以查看是否添加工厂（添加DbContextFactory https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.dependencyinjection.entityframeworkservicecollectionextensions.adddbcontextfactory?view=efcore-5.0）并使用它来创建上下文会有所帮助；再次，请参阅文档中上面引用的同一部分以获取实际代码。

如果您想知道为什么DbContext即瞬态是不确定的，您可能需要深入研究 .NET Core 代码库以查看何时回收瞬态资源。这大概就是not就在您退出处理程序之后，但在回滚（可能很深）调用堆栈之后的某个地方。

（如果是这种情况，请这样想——许多调用试图完成，因为许多调用正在展开它们的堆栈；这种短暂的情况是pressure可以在一段时间内建立）。

您的 DI 本身并没有错，但对于您想要完成的任务以及代码运行的上下文来说，它似乎并不是最佳的。