表现 – 异步等待：他们不好吗？

Is there anything silly with this method? Note that when we converted
all method to non-async methods we got a heaps better performance.

我可以看到至少有两件事情出现在这里：

public static async Task<T> GetApiResponse<T>(object parameters,ctk)
                        .ContinueWith(x => x.Result.Content
                            .ReadAsAsync<T>(new[] { formatter }).Result,ctk);
        }
    }

首先，你传递给ContinueWith的lambda是阻止：

x => x.Result.Content.ReadAsAsync<T>(new[] { formatter }).Result

这相当于：

x => { 
    var task = x.Result.Content.ReadAsAsync<T>(new[] { formatter });
    task.Wait();
    return task.Result;
};

因此，您正在阻止一个在其上执行lambda的池线程。这有效地消除了自然异步ReadAsAsync API的优势，并降低了Web应用程序的可扩展性。在您的代码中注意其他类似的地方。

其次，ASP.NET请求由安装了特殊同步上下文AspNetSynchronizationContext的服务器线程处理。当使用等待继续时，继续回调将被发布到相同的同步上下文中，编译器生成的代码将会处理这一点。 OTOH，当您使用ContinueWith时，这不会自动发生。

因此，您需要显式提供正确的任务调度程序，删除阻止的.Result(这将返回一个任务)并解开嵌套任务：

return
    await
        httpClient.PostAsJsonAsync(action,ctk).ContinueWith(
            x => x.Result.Content.ReadAsAsync<T>(new[] { formatter }),ctk,TaskContinuationOptions.None,TaskScheduler.FromCurrentSynchronizationContext()).Unwrap();

也就是说，你真的不需要这样的附加复杂性ContinueWith这里：

var x = await httpClient.PostAsJsonAsync(action,ctk);
return await x.Content.ReadAsAsync<T>(new[] { formatter });

以下文章由Stephen Toub高度相关：

“Async Performance: Understanding the Costs of Async and Await”。

If I have to call an async method in a sync context,where using await
is not possible,what is the best way of doing it?

你几乎不需要混合等待和继续，你应该坚持等待。基本上，如果你使用异步，它必须是async “all the way”。

对于服务器端ASP.NET MVC / Web API执行环境，它只是意味着控制器方法应该是异步的，并返回一个任务或任务，请检查this. ASP.NET跟踪给定HTTP请求的待处理任务。在所有任务完成之前，请求尚未完成。

如果您真的需要从ASP.NET中的同步方法调用异步方法，则可以使用像this这样的AsyncManager来注册待处理的任务。对于经典的ASP.NET，您可以使用PageAsyncTask。

在最坏的情况下，您可以调用task.Wait()并阻止，否则您的任务可能会继续超出该特定HTTP请求的边界。

对于客户端UI应用程序，从同步方法调用异步方法可能会有一些不同的情况。例如，您可以使用ContinueWith(action，TaskScheduler.FromCurrentSynchronizationContext())并从动作触发完成事件(如this)。