使用Task.WhenAll和Parallel.ForEach搭配EF Core DataContext结果不一致问题

你给出的上下文代码如下：

using (var scope = serviceProvider.CreateScope()) {
    var ctx = scope.ServiceProvider.GetRequiredService<IEFCoreDataContext>();
    // async operations on ctx and entity (see below for entity)
    await ctx.SaveChangesAsync();
}

错误的并行实现：

await Task.Run(() => Parallel.ForEach(list, async entity => {
    <snippet>
});

正常运行的异步实现：

await Task.WhenAll(
    list.Select(
        async entity => {
            <snippet>
        }
    )
);

1. Parallel.ForEach 原生不支持异步委托 #

Parallel类的所有公开重载仅接受Action<>类型的同步委托，你传入的async entity => { ... }异步lambda会被隐式转换为async void类型，而非可等待的Func<Task>类型。
这直接导致Parallel.ForEach不会等待异步操作（比如SaveChangesAsync这类IO操作）完成，只要委托的同步部分执行完毕就会认为迭代结束，外层的await Task.Run(...)会提前返回，会引发三类问题：

• 如果你的IEFCoreDataContext实例是在Parallel.ForEach外部初始化的，上下文会在异步操作还没执行完时就被作用域释放，后续操作访问已销毁的对象抛出异常
• 未被等待的异步操作会同时运行，全部访问非线程安全的DbContext实例，直接触发EF Core的并发访问限制报错
• 异步操作抛出的异常会以async void的形式直接抛出到线程池上下文，无法被外层的异常捕获逻辑处理

2. 适用场景不匹配 #

Parallel类是为CPU密集型任务设计的并行调度组件，会根据CPU核心数做分区、占用线程池线程执行同步计算。而EF Core的数据库操作是典型的IO密集型任务，用Parallel调度会额外浪费线程池资源，且无法适配异步IO的调度逻辑。 #

为什么Task.WhenAll写法能正常运行 #

list.Select(async entity => { ... })会返回IEnumerable<Task>集合，Task.WhenAll会正确等待所有异步任务的状态机执行到完成，不会出现提前释放资源的问题。如果你的snippet逻辑中是每个迭代单独创建作用域、获取独立的IEFCoreDataContext实例，还能完全避免多个操作并发访问同一个DbContext的问题，符合EF Core的使用规范。

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