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

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

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

一、背景

1. 讲故事

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

大概就是说在 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  查看即可，如下图所示：

从图中可以清晰的看出 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, 说干就干。

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

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

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

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

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

三、破解之法

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

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

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

2. 禁止阻塞主线程

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

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