关于c＃：HttpClient.GetAsync（…）在使用await / async时永远不会返回

HttpClient.GetAsync(…) never returns when using await/async

编辑：这个问题看起来可能是同一个问题，但没有回答…

编辑：在测试用例5中，任务似乎停留在WaitingForActivation状态。

我在.NET 4.5中使用system.net.http.httpclient时遇到了一些奇怪的行为，在这种情况下，"等待"对(例如)httpClient.GetAsync(...)的调用的结果将永远不会返回。

只有在使用新的异步/等待语言功能和任务API时，才会出现这种情况——当只使用延续时，代码似乎总是可以工作的。

下面是一些重现问题的代码-将其放到Visual Studio 11中的新"MVC 4 WebAPI项目"中，以公开以下get端点：

1
2
3
4
5
6

/api/test1
/api/test2
/api/test3
/api/test4
/api/test5 <--- never completes
/api/test6

这里的每个端点都返回相同的数据(stackoverflow.com的响应头)，但/api/test5除外，它永远不会完成。

我是否在httpclient类中遇到了错误，或者我在某种程度上使用了API？

要复制的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104

public class BaseApiController : ApiController
{
/// <summary>
/// Retrieves data using continuations
/// </summary>
protected Task<string> Continuations_GetSomeDataAsync()
{
var httpClient = new HttpClient();

var t = httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead);

return t.ContinueWith(t1 => t1.Result.Content.Headers.ToString());
}

/// <summary>
/// Retrieves data using async/await
/// </summary>
protected async Task<string> AsyncAwait_GetSomeDataAsync()
{
var httpClient = new HttpClient();

var result = await httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead);

return result.Content.Headers.ToString();
}
}

public class Test1Controller : BaseApiController
{
/// <summary>
/// Handles task using Async/Await
/// </summary>
public async Task<string> Get()
{
var data = await Continuations_GetSomeDataAsync();

return data;
}
}

public class Test2Controller : BaseApiController
{
/// <summary>
/// Handles task by blocking the thread until the task completes
/// </summary>
public string Get()
{
var task = Continuations_GetSomeDataAsync();

var data = task.GetAwaiter().GetResult();

return data;
}
}

public class Test3Controller : BaseApiController
{
/// <summary>
/// Passes the task back to the controller host
/// </summary>
public Task<string> Get()
{
return Continuations_GetSomeDataAsync();
}
}

public class Test4Controller : BaseApiController
{
/// <summary>
/// Handles task using Async/Await
/// </summary>
public async Task<string> Get()
{
var data = await AsyncAwait_GetSomeDataAsync();

return data;
}
}

public class Test5Controller : BaseApiController
{
/// <summary>
/// Handles task by blocking the thread until the task completes
/// </summary>
public string Get()
{
var task = AsyncAwait_GetSomeDataAsync();

var data = task.GetAwaiter().GetResult();

return data;
}
}

public class Test6Controller : BaseApiController
{
/// <summary>
/// Passes the task back to the controller host
/// </summary>
public Task<string> Get()
{
return AsyncAwait_GetSomeDataAsync();
}
}

相关讨论

您滥用了API。

情况如下：在ASP.NET中，一次只能有一个线程处理请求。如果需要，您可以执行一些并行处理(从线程池借用其他线程)，但只有一个线程具有请求上下文(其他线程没有请求上下文)。

这是由ASP.NET SynchronizationContext管理的。

默认情况下，当您使用await一个Task时，该方法将在一个捕获的SynchronizationContext上恢复(如果没有SynchronizationContext的话，则在一个捕获的TaskScheduler上恢复)。通常情况下，这正是您想要的：异步控制器操作将需要cx1〔0〕一些东西，当它恢复时，它将与请求上下文一起恢复。

所以，这就是test5失败的原因：

Test5Controller.Get执行AsyncAwait_GetSomeDataAsync(在ASP.NET请求上下文中)。
AsyncAwait_GetSomeDataAsync执行HttpClient.GetAsync(在ASP.NET请求上下文中)。
发送HTTP请求，HttpClient.GetAsync返回未完成的Task。
AsyncAwait_GetSomeDataAsync等待Task；由于它不完整，AsyncAwait_GetSomeDataAsync返回未完成的Task。
Test5Controller.Get阻塞当前线程，直到该Task完成。
HTTP响应进入，HttpClient.GetAsync返回的Task完成。
AsyncAwait_GetSomeDataAsync尝试在ASP.NET请求上下文中恢复。但是，该上下文中已经有一个线程：该线程在Test5Controller.Get中被阻塞。
死锁。

这就是为什么其他方法有效：

(test1、test2和test3：Continuations_GetSomeDataAsync在ASP.NET请求上下文之外，将继续调度到线程池。这使得由Continuations_GetSomeDataAsync返回的Task可以在不必重新进入请求上下文的情况下完成。
(test4和test6：由于Task等待，ASP.NET请求线程没有被阻塞。这允许AsyncAwait_GetSomeDataAsync在准备好继续时使用ASP.NET请求上下文。

以下是最佳实践：

在您的"库"async方法中，尽可能使用ConfigureAwait(false)。在你的情况下，这会把AsyncAwait_GetSomeDataAsync改为var result = await httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead).ConfigureAwait(false);。

不要挡在Task上，一路往下就是async。换言之，使用await代替GetResult(Task.Result)，Task.Wait也应替换为await。

这样，您就得到了两个好处：继续(AsyncAwait_GetSomeDataAsync方法的其余部分)是在基本线程池线程上运行的，该线程不必进入ASP.NET请求上下文；控制器本身是async(它不阻塞请求线程)。

更多信息：

我的async/await介绍帖子，其中简要介绍了Task等待者如何使用SynchronizationContext。
Async/Await常见问题解答，将详细介绍上下文。还可以看到等待、用户界面和死锁！哦，我的天哪！尽管您是在ASP.NET中而不是在UI中，但这里确实适用，因为ASP.NET SynchronizationContext一次只将请求上下文限制为一个线程。
此msdn论坛帖子。
StephenToub演示了这个死锁(使用UI)，LucianWischik也演示了这个死锁。

更新2012-07-13：将此答案并入博客帖子。

相关讨论

是否有一些关于ASP.NET SynchroniztaionContext的文档解释了对于某些请求，上下文中只能有一个线程？如果没有，我想应该有。
在阿法克的任何地方都没有记录。
谢谢-反应真棒。在功能上完全相同的代码之间的行为差异是令人沮丧的，但是你的解释是有意义的。如果框架能够检测到这种死锁并在某个地方引发异常，这将非常有用。
是否存在不建议在ASP.NET上下文中使用.configureawait(false)的情况？在我看来，它应该总是被使用，而且它只在一个UI上下文中使用，因为您需要同步到UI。或者我错过了要点？
ASP.NET SynchronizationContext确实提供了一些重要的功能：它流动请求上下文。这包括各种各样的东西，从认证到cookie到文化。因此，在ASP.NET中，不同步回UI，而是同步回请求上下文。这可能很快就会改变：新的ApiController确实有一个HttpRequestMessage上下文作为属性，因此可能不需要通过SynchronizationContext来传递上下文，但我还不知道。
谢谢您！我错误地使用了task.waitall而不是wait task.whenall。你的回答让我走上正轨
在简介中，您有公共任务myoldtaskParallelLibraryCode()(task without async)您在这里返回什么？因为编译器希望您返回一个任务。如何创建空任务？
@BART：旧式的TPL代码通常使用Task.Factory.StartNew或TaskCompletionSource。注意，对于大多数现代代码，不推荐使用StartNew。
@史蒂芬克利里我不熟悉旧风格(老实说，也不熟悉新风格)。我正在使用新的样式，我希望一个CPU密集型的任务是异步运行的，但里面没有任何等待方法。(更像是流自定义分析器)。你建议我回去做什么？
@BART:同步方法应该有一个同步API。如果您想异步调用它(即保持UI响应)，那么可以使用Task.Run调用它。我有一个Task.Run礼仪博客系列，详细介绍。
@斯蒂芬克利里几乎掉进了一个陷阱，为卸载包装一个同步方法。不仅它有意义，而且它更清楚何时以及如何使用异步，它还使代码更加容易！！如果可以的话我会加100。
@那么，如果你在控制器中间调用response.GetStringAsAsync().Result，为什么它不会导致死锁呢？基本上，为什么每次调用.NET Web应用程序内部的.NET对象时都没有死掉的结果？看起来这应该是同一个问题——在用户界面上下文中访问它，在那里等待将在lib的某个地方发生。
@stephencleary——那么在同一个上下文中，在.Result中使用await是主要问题吗？我无法在控制台应用程序中重现这种问题。
@mmcrae：死锁是由捕获的上下文(例如，SynchronizationContext的存在)和阻塞该任务的上下文造成的。控制台应用程序没有SynchronizationContext。同样，GetStringAsAsync()也没有捕获上下文(在该平台上)。
@stephencleary-是否有一些文档表明该方法不会捕获/阻止UI上下文？有些人会，有些人不会，这似乎很奇怪。(msdn.microsoft.com/en-us/library/&hellip；是我打算提出的实际方法)
@mmcrae:ms apis尝试不捕获上下文。有时他们会出错(很容易出错)。我不知道它的任何文档，您不应该依赖它——它是一个实现细节。
@stephencleary——我想这就是为什么你一直建议使用await，因为它最安全，不受实现更改等的影响。如果我们真的需要在请求期间阻塞，应该使用Task.Run(() => ...，这会将它放入线程池。
@嗯，是的，这是一个一直走下去的原因。如果您确实需要阻塞，那么最好一直使用同步API，例如WebClient。它们是为阻挡而设计的。

编辑：通常尽量避免做下面的工作，除了最后一点努力避免死锁。阅读斯蒂芬·克利里的第一条评论。

从这里快速修复。不是写：

1 2	Task tsk = AsyncOperation(); tsk.Wait();

尝试:

1	Task.Run(() => AsyncOperation()).Wait();

或者如果你需要一个结果：

1	var result = Task.Run(() => AsyncOperation()).Result;

从源(编辑以匹配上述示例)：

AsyncOperation will now be invoked on the ThreadPool, where there
won’t be a SynchronizationContext, and the continuations used inside
of AsyncOperation won’t be forced back to the invoking thread.

对于我来说，这看起来是一个可用的选项，因为我没有让它一直异步的选项(我更喜欢)。

来源：

Ensure that the await in the FooAsync method doesn’t find a context to
marshal back to. The simplest way to do that is to invoke the
asynchronous work from the ThreadPool, such as by wrapping the
invocation in a Task.Run, e.g.

int Sync() {
return Task.Run(() => Library.FooAsync()).Result; }

FooAsync will now be invoked on the ThreadPool, where there won’t be a
SynchronizationContext, and the continuations used inside of FooAsync
won’t be forced back to the thread that’s invoking Sync().

相关讨论

可能需要重新读取源链接；作者建议不要这样做。它起作用了吗？是的，但只有在避免死锁的意义上。此解决方案否定了ASP.NET上的async代码的所有好处，实际上可能导致大规模问题。顺便说一句，ConfigureAwait在任何情况下都不会"破坏适当的异步行为"；这正是您在库代码中应该使用的。
我重新阅读了我的源链接。找不到您所指的内容。但是，如果"现实世界的例子"一章读错了，听起来他可能建议不要这样做，但事实上，他正在处理一个完全不同的案例。
这是整个第一部分，用粗体Avoid Exposing Synchronous Wrappers for Asynchronous Implementations命名。如果你绝对需要的话，文章的其余部分将解释一些不同的方法。
添加了我在源代码中找到的部分-我将留给未来的读者来决定。请注意，一般情况下，您应该尽量避免这样做，并且只将它作为最后的手段(即，当使用不受控制的异步代码时)。
我喜欢这里所有的答案，和往常一样……它们都是基于上下文的(双关语是指lol)。我正在用同步版本包装httpclient的异步调用，因此我无法更改该代码以将configureAwait添加到该库中。为了防止生产中的死锁，我将异步调用包装在task.run中。据我所知，这将为每个请求额外使用一个线程，并避免死锁。我假设要完全兼容，我需要使用WebClient的同步方法。这是很多工作需要证明的，所以我需要一个令人信服的理由，不坚持我目前的方法。
顺便说一下，我需要通过异步进行同步的原因是因为我需要在一个已经异步的控制器方法中调用一个Web服务，而它调用它a sync导致了"async在等待时返回async"问题。也许我现在有时间解决这个问题：)
@samneric-所以你用Task.Run(() => ...).Result包装httpclient的异步调用，对吗？我也有类似的情况。结果如何？
我最终创建了一个扩展方法来将异步转换为同步。我在这里读到了与.NET框架相同的地方：public static tresult runsync(this func>func)return taskfactory.startnew(func.unwrap().getawaiter().getresult()；

由于您使用的是.Result或.Wait或await，这将导致代码死锁。

在async方法中可以使用ConfigureAwait(false)来防止死锁。

这样地：

1 2	var result = await httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead) .ConfigureAwait(false);

you can use ConfigureAwait(false) wherever possible for Don't Block Async Code .

这两所学校并不排除在外。

以下是您只需使用的场景

1	Task.Run(() => AsyncOperation()).Wait();

或者类似的

1	AsyncContext.Run(AsyncOperation);

我有一个MVC操作，它在数据库事务属性下。这个想法是(很可能)如果出了什么问题，就把行动中所做的一切都回滚。这不允许上下文切换，否则事务回滚或提交本身将失败。

我需要的库是异步的，因为它应该运行异步的。

唯一的选择。将其作为普通同步调用运行。

我只是对每个人说自己的话。

相关讨论

我将把它放在这里更多的是为了完整性而不是与操作直接相关。我花了将近一天的时间调试了一个HttpClient请求，想知道为什么我一直没有得到回复。

最后发现我忘了把await调用放在调用堆栈的后面。

感觉就像丢了一个分号一样好。

我看这里：

http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.taskwaiter(v=vs.110).aspx

这里：

http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.taskwaiter.getresult(v=vs.110).aspx

看到：

This type and its members are intended for use by the compiler.

考虑到await版本是有效的，并且是正确的做法，您真的需要回答这个问题吗？

我的投票是：滥用API。

相关讨论