Asp.Net MVC中Task.Run封装同步批量数据库操作是否等效于原生异步？

结论 #

你提供的Task.Run包装同步方法的写法，和原生异步批量操作的效果完全不一致，从IIS线程池的工作机制来看，甚至不会比直接同步调用带来性能提升，高并发场景下反而会更差。

核心差异原理 #

IIS的请求处理依赖.NET线程池的工作线程，异步IO的核心价值是在IO等待阶段释放线程池线程，提升线程池的吞吐量，两种写法的底层行为差异如下：

• 原生异步批量方法（比如Z.EntityFramework.Extensions提供的BulkUpdateAsync）：属于真正的异步IO操作，触发数据库请求后会立即释放当前占用的线程池线程回到线程池，整个数据库IO等待过程不占用任何线程池资源，IO操作完成后才会重新从线程池调度线程执行后续逻辑，能大幅提升高并发场景下的请求承载能力。
• 你当前使用的await Task.Run(() => BulkUpdate())写法：只是把同步阻塞的批量操作从原请求线程转移到了另一个线程池线程执行，整个数据库IO等待过程中仍然会占用1个线程池线程，没有节省任何线程资源，反而额外产生了线程上下文切换的开销，高并发场景下会加速线程池耗尽，导致请求排队、响应超时等问题。

场景建议 #

• 如果你的应用并发量不高，批量操作的频率和数据量都很小，直接同步调用MyDatabaseContext.BulkUpdate(entities)即可，没必要套Task.Run做无意义的包装。
• 如果并发量较高、必须依赖异步能力提升吞吐量，可以根据团队预算选择付费的Z.EntityFramework.Extensions，或者自行实现拼接批量更新SQL的逻辑，通过EF原生的ExecuteSqlCommandAsync执行异步操作。

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