一：背景
1. 讲故事
前些天把 .NET 高级调试 方面的文章索引到 github 的过程中，发现了一个有意思的评论，详见 文章，截图如下：
大略就是说在 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<string> 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 Site0000004d10dfde00 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 000001f19002fcf0Thread 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+<GetJsonAsync>d__2 -> 000001f1800b4e50 System.Threading.Tasks.Task`1[[System.String, mscorlib]] -> 000001f19002fcf0 System.StringFound 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 即可。
三：总结
论断就是多本人实操实操，理论知识是他人强制灌输给你的，到底对还是不对，其实你本人心里也没底，实操验证才是真正属于你的，而且也很难遗记，毕竟你曾今真的体验过，实操过，验证过。
更多高质量干货：参见我的 GitHub: dotnetfly