一句 Task.Result 就死鎖, 這程式碼還怎麼寫？

一線碼農發表於2021-05-11

一：背景

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 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+<GetJsonAsync>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 即可。

三：總結

結論就是多自己實操實操，理論知識是別人強制灌輸給你的，到底對還是不對，其實你自己心裡也沒底，實操驗證才是真正屬於你的，而且也很難忘記，畢竟你曾今真的體驗過，實操過，驗證過。

更多高質量乾貨：參見我的 GitHub: dotnetfly

圖片名稱

相關文章