ASP.NET Core 2中异步/同步Action方法请求阻塞问题排查

嘿，这个场景我太熟悉了——本质上是ASP.NET Core的线程池请求处理机制，加上你写的“伪异步”代码共同导致的请求排队问题，咱们一步步说清楚：

核心根源：线程池线程耗尽引发请求排队 #

ASP.NET Core依赖.NET的线程池来处理所有进来的HTTP请求。默认情况下，线程池的最小工作线程数和CPU核心数挂钩（比如4核机器默认最小是4个）。当同时进来的请求数超过可用线程数时，后续请求只能排队等待，直到前面的线程被释放才能被处理。

同步Action的问题一目了然 #

先看你的同步方法：

public IActionResult Index() 
{ 
    for (int k = 0; k < int.MaxValue; k++) { } 
    return View(); 
}

这个方法从执行到结束，会死死占用一个线程池线程整整5秒——线程完全被空循环阻塞，根本没法处理其他请求。当你开5个标签页同时发起请求时，前几个请求会占满所有可用线程，第5个只能等前面的请求逐个执行完（每个5秒），最后总耗时就是5×5=25秒，完全符合你看到的现象。

你的异步Action是“伪异步”，根本没发挥作用 #

再看你写的异步方法：

public async Task<IActionResult> Index() 
{ 
    for (int k = 0; k < int.MaxValue / 2; k++) { 
        await Task.Delay(0); 
    } 
    return View(); 
}

虽然用了async/await语法，但这是典型的伪异步！Task.Delay(0)会立即返回一个已完成的Task，await它的时候，线程根本不会被释放回线程池，而是直接同步继续执行下一次循环。整个方法从头到尾还是在占用一个线程池线程跑空循环，和同步版本的行为几乎一模一样，自然也会导致请求排队，最后一个请求耗时25秒。

如何写出真正能提升并发的异步代码 #

异步的核心价值是在IO等待阶段释放线程（比如数据库查询、HTTP调用、文件读写这些需要等待外部资源的操作）。如果你的实际业务中有这类IO操作，正确的写法应该是await对应的异步方法，比如：

public async Task<IActionResult> Index() 
{
    // 示例：异步查询数据库
    var userData = await _userRepository.GetAllUsersAsync();
    // 或者异步调用外部API
    var remoteResponse = await _httpClient.GetAsync("https://your-api-endpoint.com");
    
    return View(userData);
}

这种情况下，当await IO操作时，当前线程会被释放回线程池，去处理其他请求；等IO操作完成后，线程池再分配一个线程继续执行后续代码。这样就能同时处理远多于CPU核心数的请求，不会出现严重的排队问题。

最后总结一下 #

• 同步Action会阻塞线程池线程，并发场景下必然导致请求排队，性能拉胯；
• 你的异步Action是伪异步，因为没有真正的IO等待，线程根本没被释放；
• 只有当await的是真正的异步IO操作时，才能发挥异步的优势，提升系统的并发处理能力。

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