ASP.NET与ASP.NET Core中await行为差异及Core2.0请求问题咨询

好问题！await运算符在传统ASP.NET和ASP.NET Core中的行为确实存在关键差异，尤其是在请求线程调度和并发处理逻辑上，咱们结合你遇到的场景一步步拆解：

一、传统ASP.NET的await行为 #

传统ASP.NET依赖ASP.NET同步上下文（ASP.NET Synchronization Context），这个上下文有两个核心特点：

• 异步操作完成后，会强制回到原请求的线程（或同类型的线程）继续执行后续代码
• 如果你的应用启用了Session，默认会持有独占式Session锁——即使请求执行到await释放了线程，这个锁也不会释放，导致同一会话的后续请求必须排队到当前请求完全结束才能处理

简单说，在传统ASP.NET里，哪怕你用了await，同会话的第二个请求也没法在第一个请求await期间被处理，必须等整个请求跑完。

二、ASP.NET Core的await行为 #

ASP.NET Core彻底移除了传统的同步上下文，改用轻量的请求上下文模型，同时对Session锁做了优化：

• 当请求执行到await时，处理该请求的线程会立即释放回线程池，不会被挂起等待异步操作完成
• 线程池会立刻把空闲线程分配给等待中的第二个请求（也就是你的action2），让它开始处理
• 当第一个请求的await任务完成后，线程池再分配任意空闲线程继续处理action1的剩余代码

这正是你看到的现象：第一个请求到await时，第二个请求马上启动处理，第一个请求进入等待状态（不是排队，是等待异步任务完成）——这完全是ASP.NET Core的预期设计，目的是最大化线程池利用率，提升应用的并发吞吐量。

额外补充两个和你的场景相关的细节：

• 如果你的两个请求都涉及Session操作：ASP.NET Core默认允许并发读取Session，但写入Session时会触发独占锁，这时候第二个请求还是会排队；如果只是读Session，就能像你看到的那样并发处理
• ASP.NET Core 2.0的这个行为在后续版本中没有本质变化，都是基于无同步上下文的异步调度模型

内容的提问来源于stack exchange，提问作者Jose Emilio Cabana