如何在DbContext上正确并发执行多个操作？

你遇到的异常是EF Core的明确设计约束：DbContext实例天生不支持线程安全，绝对不能在多个并行任务中共享同一个实例做读写操作，不管你把它注册为Scoped还是Transient生命周期，只要多个线程同时操作同一个实例，就必然抛出这个异常。
你之前把DbContext注册为Transient没解决问题的原因很简单：你在每个循环块里只调用了一次GetRequiredService<DataContext>()，整个块里从头到尾就用了这一个实例。Transient生命周期的规则是「每次从ServiceProvider请求实例时返回新对象」，你没有重复请求，自然拿不到新实例，并发冲突完全没有被解决。

针对你提的两个疑问直接给结论：

• 你创建DbContext的语法没有错，但用法错了：不该把同一个实例传给并行任务
• 给每个并行工作单元分配独立DbContext就是EF Core官方推荐的标准实践，你担心的性能问题完全是多余的。

你觉得每秒创建20个DbContext、执行20次SaveChanges效率低，这个认知不符合实际：

• DbContext是极轻量的对象，它的模型映射、元数据配置等重量级资源是全局共享的，新建实例的开销只有实体跟踪器的初始化，成本低到可以忽略，哪怕每秒创建上百个实例都不会造成可观测的性能损耗
• 你用的是内存数据库（InMemoryDatabase），本身没有磁盘IO、网络IO开销，多实例操作的成本比你预想的低得多
• 反过来，强行让多个并行任务共用一个DbContext，除了会触发线程安全异常，还会因为跟踪器持续累积所有操作过的实体，长期运行后内存占用越来越高，变更检测的耗时也会线性上涨，对于常驻后台的服务来说反而会造成更严重的性能问题。
• 另外你代码里写的await Task.Delay(0, stoppingToken)没有任何轮询限流作用，相当于任务完成后立刻开启下一轮循环，会导致CPU无意义空转，建议根据业务需求设置合理的间隔，比如1000ms对应你说的1秒一次轮询。

方案1（改造成本最低，推荐优先使用） #

每个并行任务独立创建Scope、获取专属DbContext实例，完全规避线程安全问题：

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    while (!stoppingToken.IsCancellationRequested)
    {
        var tasks = new List<Task>
        {
            ProcessSingleSite(SportLeagues.MLB, siteA, stoppingToken),
            ProcessSingleSite(SportLeagues.MLB, siteB, stoppingToken)
            // 追加其他站点的处理任务
        };

        await Task.WhenAll(tasks);
        await Task.Delay(1000, stoppingToken); // 按实际需求调整轮询间隔
    }
}

private async Task ProcessSingleSite(SportLeagues league, ISiteProcessor site, CancellationToken stoppingToken)
{
    // 每个任务独立创建服务范围，scope释放时DbContext会自动被销毁
    using var scope = _scopeFactory.CreateScope();
    var dbContext = scope.ServiceProvider.GetRequiredService<DataContext>();
    var logger = scope.ServiceProvider.GetRequiredService<ILogger<YourBackgroundService>>();

    await site.ProcessSchedule(league, logger, dbContext);
    await dbContext.SaveChangesAsync(stoppingToken);
}

这个写法完全符合EF Core的使用规范，在你20并行、1秒一轮的场景下没有任何性能瓶颈。

方案2（追求更低的DbContext和SaveChanges开销） #

把数据抓取/处理逻辑和数据库写入逻辑拆开：并行执行所有不依赖DbContext的数据拉取、清洗工作，等所有任务都返回需要持久化的数据后，再用单个DbContext统一写入，只执行一次SaveChanges：

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    while (!stoppingToken.IsCancellationRequested)
    {
        // 并行执行纯数据处理逻辑，这部分不操作DbContext，不存在线程安全问题
        var fetchTasks = new List<Task<IEnumerable<ScheduleEntity>>>
        {
            siteA.FetchAndCleanSchedulesAsync(SportLeagues.MLB, stoppingToken),
            siteB.FetchAndCleanSchedulesAsync(SportLeagues.MLB, stoppingToken)
            // 追加其他站点的抓取任务
        };

        var allScheduleGroups = await Task.WhenAll(fetchTasks);

        // 所有数据准备完成后，用单个DbContext批量写入
        using var scope = _scopeFactory.CreateScope();
        var dbContext = scope.ServiceProvider.GetRequiredService<DataContext>();
        foreach (var scheduleGroup in allScheduleGroups)
        {
            dbContext.Schedules.AddRange(scheduleGroup);
            // 更新逻辑可在这里做实体状态匹配
        }
        await dbContext.SaveChangesAsync(stoppingToken);

        await Task.Delay(1000, stoppingToken);
    }
}

这个方案把DbContext实例创建和SaveChanges的频率降到了1秒1次，性能更高，但需要你把原来ProcessSchedule里耦合的数据库操作逻辑拆出来，改造成不依赖DbContext的纯数据处理方法，改造成本稍高。

补充：不要尝试给单个DbContext加锁来实现并行共用，锁会把所有数据库操作串行化，既失去了并行的意义，还会引入死锁、跟踪器膨胀等额外问题，完全得不偿失。

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