c# - 即使使用 ConfigureAwait(false)，在 WebAPI 中同步调用异步方法也会死锁

Question

我有 nuget 包 Esri.ArcGISRuntime我需要调用方法 QueryTask.ExecuteAsync在我的一个 Web API 2 Controller 中。没有同步计数器部分，所以在我的库 C# 代码中，我使用了类似

的包装器

    private QueryResult ExecuteSync()
    {
        var queryResults = ExecuteAsync();
        queryResults.Wait();
        return queryResults.Result;
    }

    private async Task<QueryResult> ExecuteQueryTaskAsync()
    {
        var queryTask = new QueryTask(_uri);
        return await queryTask.ExecuteAsync(_query).ConfigureAwait(false);
    }

这在我的程序/服务中完美运行。但是在 Web API 2 Controller 中以这种方式使用 ExecuteSync 会导致它完全卡住并且永远不会返回响应。

我做了一些研究，相信这里提到了罪魁祸首: http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html

我绝对不想异步使用函数。上面的函数是如此核心并且隐藏在 4 个包装器中，以至于我的库类将是一个重大的检修来冒泡异步方法只是为了支持这个 web api 调用。

我正在寻找围绕 Web API 的这种奇怪行为的变通方法/技巧/建议，以允许我同步运行此异步方法而不会使其死锁

Answer 1

I absolutely do not want to use the function asynchronously.

不过，我不得不说。异步代码是最好的解决方案。您正在执行的操作是异步的，为其公开同步 API 充其量是有问题的。

需要时间吗？当然。但是您的代码会因此变得更好。

I am looking for work-arounds/hacks/suggestions

我有an entire article on the subject of brownfield async development ，我在其中介绍了所有已知的技巧及其缺点。

在您的特定情况下(从非核心 ASP.NET 上的 WebApi 调用 并且 考虑到它确实可以从控制台/Win32Service 风格的应用程序运行)，我认为 Thread Pool Hack 应该为你工作。它看起来像这样:

private QueryResult ExecuteSync()
{
  return Task.Run(() => ExecuteAsync()).GetAwaiter().GetResult();
}

想法是 ExecuteAsync 在请求上下文之外的线程池线程上运行。然后请求线程被阻塞，直到异步工作完成。