如何解决Task.Result就死锁的问题

如何解决Task.Result就死锁的问题，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

我们提供的服务有：网站设计、成都做网站、微信公众号开发、网站优化、网站认证、神木ssl等。为上1000+企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的神木网站制作公司

一、背景

1. 讲故事

前些天把 .NET 高级调试方面的文章索引到 https://github.com/ctripxchuang/dotnetfly 的过程中，发现了一个有意思的评论，截图如下：

如何解决Task.Result就死锁的问题

大概就是说在 Winform 的主线程下执行 Task.Result 会造成死锁，我也看了图中的参考链接, Stephen 是绝对的大佬，不过这篇文章对死锁的成因主要还是大段的文字灌输，没有真的让你眼见为实，那这篇我就从 windbg 的角度来给它剖析下。

二、windbg 分析

1. 真的会死锁吗?

看文章看截图貌似真的会死锁，当然我多年不玩 winform 了，也搞不清楚到底会不会，至少在 Console 中是不会的，得，先上一段测试代码。

public partial class Form1 : Form     {         public Form1()         {             InitializeComponent();         }          private void button1_Click(object sender, EventArgs e)         {             var jsonTask = GetJsonAsync("http://cnblogs.com").Result;             textBox1.Text = jsonTask;         }          public async static Task GetJsonAsync(string uri)         {             using (var client = new HttpClient())             {                 var jsonString = await client.GetStringAsync(uri);                  return jsonString;             }         }     }

代码非常简单，把程序跑起来，点一下 click，果然界面卡住了，有点不可思议。

2. 寻找死锁原因

接下来赶紧祭出 windbg 附加到进程上一探究竟吧。

1) 查看主线程

界面无响应了，自然是主线程卡住了，所以急需看一下此时的主线程在干嘛?用命令 ~0s + !clrstack 即可。

0:000> !clrstack  OS Thread Id: 0x5a10 (0)         Child SP               IP Call Site 0000004d10dfde00 00007ffb889a10e4 [GCFrame: 0000004d10dfde00]  0000004d10dfdf28 00007ffb889a10e4 [HelperMethodFrame_1OBJ: 0000004d10dfdf28] System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object) 0000004d10dfe040 00007ffb66920d64 System.Threading.ManualResetEventSlim.Wait(Int32, System.Threading.CancellationToken) 0000004d10dfe0d0 00007ffb6691b4bb System.Threading.Tasks.Task.SpinThenBlockingWait(Int32, System.Threading.CancellationToken) 0000004d10dfe140 00007ffb672601d1 System.Threading.Tasks.Task.InternalWait(Int32, System.Threading.CancellationToken) 0000004d10dfe210 00007ffb6725cfa7 System.Threading.Tasks.Task`1[[System.__Canon, mscorlib]].GetResultCore(Boolean) 0000004d10dfe250 00007ffb18172a1b WindowsFormsApp4.Form1.button1_Click(System.Object, System.EventArgs) [E:\net5\ConsoleApp1\WindowsFormsApp4\Form1.cs @ 26] 0000004d10dfe2b0 00007ffb3a024747 System.Windows.Forms.Control.OnClick(System.EventArgs) 0000004d10dfe2f0 00007ffb3a027b83 System.Windows.Forms.Button.OnClick(System.EventArgs) 0000004d10dfe340 00007ffb3a837231 System.Windows.Forms.Button.OnMouseUp(System.Windows.Forms.MouseEventArgs) 0000004d10dfe400 00007ffb3a7e097d System.Windows.Forms.Control.WmMouseUp(System.Windows.Forms.Message ByRef, System.Windows.Forms.MouseButtons, Int32) 0000004d10dfe480 00007ffb3a0311cc System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef) 0000004d10dfe540 00007ffb3a0b0c97 System.Windows.Forms.ButtonBase.WndProc(System.Windows.Forms.Message ByRef) 0000004d10dfe5c0 00007ffb3a0b0be5 System.Windows.Forms.Button.WndProc(System.Windows.Forms.Message ByRef) 0000004d10dfe5f0 00007ffb3a030082 System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr) 0000004d10dfe690 00007ffb3a765a02 DomainBoundILStubClass.IL_STUB_ReversePInvoke(Int64, Int32, Int64, Int64) 0000004d10dfe9d0 00007ffb776d221e [InlinedCallFrame: 0000004d10dfe9d0] System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef) 0000004d10dfe9d0 00007ffb3a0b9489 [InlinedCallFrame: 0000004d10dfe9d0] System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef) 0000004d10dfe9a0 00007ffb3a0b9489 DomainBoundILStubClass.IL_STUB_PInvoke(MSG ByRef) 0000004d10dfea60 00007ffb3a046661 System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32) 0000004d10dfeb50 00007ffb3a045fc7 System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext) 0000004d10dfebf0 00007ffb3a045dc2 System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext) 0000004d10dfec50 00007ffb181708e2 WindowsFormsApp4.Program.Main() [E:\net5\ConsoleApp1\WindowsFormsApp4\Program.cs @ 19] 0000004d10dfee78 00007ffb776d6923 [GCFrame: 0000004d10dfee78]

从堆栈输出看，主线程最后是卡在 Task.Result 下的 Monitor.ObjWait 上，也就是说它还没有取到最后的 jsonString，这就很奇怪了，都好几分钟了，难道网络出问题啦 ? 我这网可是100M火力全开。。。??????

2) jsonString 哪去了?

判断是不是网络的问题，有一个好办法，那就是直接暴力搜索托管堆，如果在托管堆上发现了 jsonString，那就说明是程序上的某些地方让 Result 迟迟得不到结束，用命令 !dumpheap -type String -min 8500 + !do 000001f19002fcf0 查看即可，如下图所示：

如何解决Task.Result就死锁的问题

从图中可以清晰的看出 html 回来了，既然都回来了，为啥还没让 Task.Result 结束呢?下一步就是看一看这个 html 被谁持有，使用 !gcroot 即可。

0:000> !gcroot 000001f19002fcf0 Thread 5a10:     0000004d10dfe250 00007ffb18172a1b WindowsFormsApp4.Form1.button1_Click(System.Object, System.EventArgs) [E:\net5\ConsoleApp1\WindowsFormsApp4\Form1.cs @ 26]         rbp+10: 0000004d10dfe2b0             ->  000001f180007f78 WindowsFormsApp4.Form1             ->  000001f180070d68 System.ComponentModel.EventHandlerList             ->  000001f180071718 System.ComponentModel.EventHandlerList+ListEntry             ->  000001f1800716d8 System.EventHandler             ->  000001f1800716b0 System.Windows.Forms.ApplicationContext             ->  000001f180071780 System.EventHandler             ->  000001f18006ab38 System.Windows.Forms.Application+ThreadContext             ->  000001f18006b140 System.Windows.Forms.Application+MarshalingControl             ->  000001f18016c9c8 System.Collections.Queue             ->  000001f18016ca00 System.Object[]             ->  000001f18016c948 System.Windows.Forms.Control+ThreadMethodEntry             ->  000001f18016c8b8 System.Object[]             ->  000001f1800e6f80 System.Action             ->  000001f1800e6f60 System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner             ->  000001f1800a77d0 WindowsFormsApp4.Form1+d__2             ->  000001f1800b4e50 System.Threading.Tasks.Task`1[[System.String, mscorlib]]             ->  000001f19002fcf0 System.String  Found 1 unique roots (run '!GCRoot -all' to see all roots).

从输出结果看，这个 System.String 最后被 5a10 线程的 WindowsFormsApp4.Form1 持有，可以用 !t 验证一下 5a10 到底是什么线程。

0:000> !t                                                                                                        Lock          ID OSID ThreadOBJ           State GC Mode     GC Alloc Context                  Domain           Count Apt Exception    0    1 5a10 000001f1f1b01200  2026020 Preemptive  000001F1800E70E8:000001F1800E7FD0 000001f1f1ad5b90 0     STA     2    2 712c 000001f1f1b2a270    2b220 Preemptive  0000000000000000:0000000000000000 000001f1f1ad5b90 0     MTA (Finalizer)

我去，5a10 竟然是主线程，真的有点混乱，主线程被卡死，string 又被主线程持有，完全是莫名其妙。

3) 寻找突破点

还是回过头下冷静思考下这条引用链，我发现这里有一个 Queue：-> 000001f18016c9c8 System.Collections.Queue，有思路了，我可以在入 Queue 的地方下个断点来调试下源代码，工具用 DNSpy, 说干就干。

如何解决Task.Result就死锁的问题

从图中可以看到，当前入Queue时，用的是线程 10，也就是说此时 string 还没被主线程持有，再仔细分析下这个调用栈，我想你应该就搞清楚了，反正我看完之后脑子中就有了这张图。

如何解决Task.Result就死锁的问题

从图中可以发现，延续的 Task 最后被 WindowsFormsSynchronizationContext.Post 调度到了 Control 下的 Queue 中，而这 Queue 中的数据需要 UI线程去执行，所以就有了下面的对话：

主线程： task小弟，你什么时候执行完呀，我在等你信号呢?

task：老哥，我已在你家啦，你什么时候过来接我呀?

总而言之：task需要主线程来执行它，主线程却在傻傻的等待 task 的 complete 状态，所以延续的task永远得不到执行，这就出现了很尴尬的场面，不知道你明白了吗? ??????

三、破解之法

知道了前因后果，这破解之法就简单了，大体上分两种。

1. 禁止将延续task 丢到 Queue 中

要切断这条路，言外之意就是让线程池自己结束这个 task，这样 UI线程就能感知到这个task已完成，最终 UI线程就能获取最后的 html，做法就是在 await 后加上 ConfigureAwait(false) , 参考如下：

如何解决Task.Result就死锁的问题

2. 禁止阻塞主线程

如果不阻塞主线程，那么主线程就可以自由的在 Control.Queue 中获取需要执行的任务，改法也很简单，只需要在 GetJsonAsync 前加上 await 即可。

如何解决Task.Result就死锁的问题

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联行业资讯频道，感谢您对创新互联的支持。

当前文章：如何解决Task.Result就死锁的问题
文章转载：http://mswzjz.cn/article/iegdso.html

网站建设知识

如何解决Task.Result就死锁的问题

一、背景

二、windbg 分析

2. 寻找死锁原因

三、破解之法

其他资讯