为了决定是异步还是同步，请比较收益和成本：

异步：

• 几乎永远不会用异步耗尽线程池（这种情况必须是极端的）
• 几乎任意级别的并发（并发请求和操作）
• 每次线程保存可节省1MB的内存
• 借助，安全的请求内并发 SynchronizationContext
• 由于减少了OS调度开销，因此在高负载情况下可以以低两位数的百分比提高吞吐量。就是说，几乎没有生产应用程序处于高CPU负载下，因为如果它接近不可用（在负载高峰的情况下，该应用程序将开始丢弃请求）

同步：

• 更简单的代码：await使99％的情况（几乎）与同步代码一样简单。也就是说，每天在Stack Overflow上出现的10多个异步问题都使用不同的语言。偏离简单路径时会出现边缘情况。同样，在使用旧版库时，例如，要求您向它们传递同步回调
• 减少编码和调试工作
• 对Profiler友好（您可以对应用程序进行配置文件，或仅暂停调试器并查看应用程序现在正在做什么。异步无法实现。）
• 与遗留代码和库完美互操作

如果要调用高延迟服务，请选择与ASP.NET异步。 Web服务可能具有高延迟。OLTP数据库几乎总是低延迟的。

如果您的应用程序受益于非常高的并发性（100+），请选择async。
大多数应用程序没有这么高的级别，或者它们的后端服务无法承受如此大的负载。使Web应用程序扩展规模没有意义，但会使后端过载。呼叫链中的所有系统都 必须
受益于高度的并发性，才能使异步受益。

典型的高延迟服务（异步的好案例）：

• 网页服务
• 等待（例如睡觉）
• 节流（SemaphoreSlim，…）
• 一些云服务（Azure）
• 对数据库的长期查询（例如报告或ETL）

典型的低延迟服务（同步的好案例）：

• 数据库调用：大多数OLTP查询都是低延迟的，因为您可以假定数据库服务器不会过载。毫无意义地抛出100个并发查询。不会使它们更快地完成。
• 文件系统：与数据库相同。

这些按 典型 情况分类。所有这些也可以属于相反的类别。

您可以在同一应用中混合使用同步和异步。 处于最佳状态时使用异步。

那么，为什么Microsoft和Entity
Framework团队推广异步使用？这是该答案的主观部分：可能是Microsoft内部政策。他们可能会预期客户端应用程序中的EF使用情况（对于此类应用程序来说，异步性非常好）。或者，他们没有意识到异步数据库调用几乎总是浪费开发人员的时间而没有好处。大多数人没有意识到这一点，因为异步是如今的方式。