使用 Async Await 是否可以避免线程耗尽？

Question

我们正在对.NET Core API 端点上的以下性能问题进行故障排除：

1. 在较小的负载下，端点始终以小于500MS 的速度返回。
2. 当我们从 3 个浏览器访问端点时，每秒一个请求，它逐渐变慢（在添加第三个浏览器进行调用的一分钟内，响应时间下降到 50,000MS 或更糟.
3. 每个额外的浏览器添加 API 使用的线程，例如40 个线程基础，第二个浏览器访问端点导致 52 个线程，第三个峰值达到 70 个，依此类推。
4. 当加载一个端点时，整个 API 会缓慢返回（所有端点）。这是我与第 3 点一起思考“线程耗尽”的主要原因。

目前的代码如下所示：

    public IActionResult GetPresentationByEvent(int eventid)
    {
      return Authorized(authDto =>
      {
        var eventList = _eventService.GetPresentationByEvent(eventid);
        return Ok(eventList)
      })
    }

我的理论是return Authorized(authDto => 持有一个线程直到它返回，导致线程耗尽。

    public async Task<IActionResult> GetPresentationByEvent(int eventid)
    {
      return Authorized(async authDto =>
      {
        Task<List<whatever>> eventList = _eventService.GetPresentationByEvent(eventid);
        return Ok(eventList)
      }
    }

Authorized 是第三方库的一部分，所以我不能轻易测试。想知道这是否是一个可能的问题/解决方案。

Answer 1

是的，异步等待可以减少线程耗尽。简而言之，当您生成的任务超出 ThreadPool 可以处理的数量时，就会出现线程耗尽。

您可以在这里查看一些细微的细节：Thread starvation and queuing

您唯一需要记住的是，您永远不应该在任务中阻塞。这意味着使用 async await 调用异步代码（并且永远不要在未完成的任务上使用 .Wait 或 .Result）。

如果你使用了一些没有使用异步等待模式的阻塞代码，你必须在专用线程（而不是任务线程队列）上生成它。

Answer 2

我的理论是 return Authorized(authDto => 持有一个线程直到它返回，导致线程耗尽。

是的。您可以通过查看方法的返回值轻松判断方法是否同步。 IActionResult 不是等待类型，所以这个方法会同步运行。

Authorized 是第三方库的一部分，所以我不能轻易测试。想知道这是否是一个可能的问题/解决方案。

可能。这完全取决于Authorized 是否可以处理异步委托。如果可以，那么这样的事情会起作用：

public async Task<IActionResult> GetPresentationByEvent(int eventid)
{
  return Authorized(async authDto =>
  {
    Task<List<whatever>> eventList = _eventService.GetPresentationByEventAsync(eventid);
    return Ok(await eventList);
  });
}

注意：

1. 任务在传递给 Ok 或其他帮助者之前应该是 awaited。
2. 这引入了GetPresentationByEventAsync，假设您的数据访问代码可以异步进行。

由于使GetPresentationByEvent 异步可能需要一些工作，因此值得在尝试此操作之前调查Authorized 是否可以接受异步委托。

使用 Async Await 是否可以避免线程耗尽？

是的，不是的。异步代码（包括async/await）确实使用更少的线程，因为它避免了阻塞线程。但是，仍然有一个限制。由于异步代码需要一个空闲线程来完成，线程耗尽仍然是可能的。使用异步代码，通常可以在遇到线程耗尽等可伸缩性问题之前实现一个或两个数量级的可伸缩性。

有关async ASP.NET 的更多概念信息，请参阅this MSDN article。