在Async/Await方法中使用ThreadPool和Task.Wait

Question

我刚刚遇到这个代码.我立即开始畏缩和自言自语(不是好事).事情是我不明白为什么,也不能合理地阐明它.它对我来说真的很糟糕 - 也许我错了.

public async Task<IHttpActionResult> ProcessAsync()
{
     var userName = Username.LogonName(User.Identity.Name);    
     var user = await _user.GetUserAsync(userName);

     ThreadPool.QueueUserWorkItem((arg) =>
        {
            Task.Run(() => _billing.ProcessAsync(user)).Wait();
        });    
     return Ok();
}

这段代码让我觉得它不必要地用ThreadPool.QueueUserWorkItem和创建线程Task.Run.此外,它看起来有可能在重负载时出现死锁或造成严重的资源问题.我对么？

_billing.ProcessAsync()方法是等待的(异步),所以我希望一个简单的"await"关键字是正确的,而不是所有这些其他的包袱.

Answer 1

我相信斯科特对他ThreadPool.QueueUserWorkItem 应该做的 猜测是正确的HostingEnvironment.QueueBackgroundWorkItem.然而,调用Task.Run和Wait完全没有意义 - 当代码已经在线程池上时,它们将工作推送到线程池并阻塞线程池线程.

_billing.ProcessAsync()方法是等待的(异步),所以我希望一个简单的"await"关键字是正确的,而不是所有这些其他的包袱.

我非常同意.

但是,这将改变操作的行为.现在它将等到Billing.ProcessAsync完成,而在它提前返回之前.请注意,早期返回ASP.NET几乎总是一个错误 - 我会说任何"计费"处理都会更加错误.因此,替换此混乱await将使应用程序更正确,但它将导致ProcessAsync操作需要更长时间才能返回到客户端.