一個高頻問題：異步操作會創建線程嗎？

2022 年 4 月 1 日
筆記
C#遺忘系列, windbg

這個問題在微信上被別人問過好多次，想來想去覺得有必要統一解答下，先說下我的答案：可能會，也有可能不會。

要想尋找答案，需要從 異步處理 的底層框架說起。

一：異步底層是什麼

異步 從設計層面上來說它就是一個 發佈訂閱者 模式，畢竟它的底層用到了 端口完成隊列，可以從 IO完成端口內核對象 所提供的三個方法中有所體現。

CreateIoCompletionPort

可以粗看下簽名：


HANDLE WINAPI CreateIoCompletionPort(
  _In_     HANDLE    FileHandle,
  _In_opt_ HANDLE    ExistingCompletionPort,
  _In_     ULONG_PTR CompletionKey,
  _In_     DWORD     NumberOfConcurrentThreads
);

這個方法主要是將 文件句柄 和 IO完成端口內核對象 進行綁定，其中的 NumberOfConcurrentThreads 表示完成端口最多允許 running 的線程上限。

PostQueuedCompletionStatus

再看簽名：


BOOL WINAPI PostQueuedCompletionStatus(
  _In_     HANDLE       CompletionPort,
  _In_     DWORD        dwNumberOfBytesTransferred,
  _In_     ULONG_PTR    dwCompletionKey,
  _In_opt_ LPOVERLAPPED lpOverlapped
);

這個函數的作用就是將一個 包 通過 內核對象 丟給 驅動設備程序 ，由後者與硬件交互，比如文件。

GetQueuedCompletionStatus

看簽名：


BOOL GetQueuedCompletionStatus(
  [in]  HANDLE       CompletionPort,
        LPDWORD      lpNumberOfBytesTransferred,
  [out] PULONG_PTR   lpCompletionKey,
  [out] LPOVERLAPPED *lpOverlapped,
  [in]  DWORD        dwMilliseconds
);

這個方法嘗試從 IO完成端口內核對象 中提取 IO 包，如果沒有提取到，那麼就會無限期等待，直到提取為止。

對上面三個方法有了概念之後，接下來看下結構圖：

這張圖非常言簡意賅，不過只畫了 端口完成隊列, 其實還有三個與IO線程有關的隊列，分別為：等待線程隊列， 已釋放隊列, 已暫停隊列，接下來我們稍微解讀一下。

當 線程t1 調用 GetQueuedCompletionStatus 時，假使此刻 任務隊列q1 無任務，那麼 t1 會卡住並自動進去 等待線程隊列 ，當某個時刻 q1 進了任務（由驅動程序投遞的），此時操作系統會將 t1 激活來提取 q1 的任務執行，同時將 t1 送到已釋放隊列中。

這個時候就有兩條路了。

遇到 Sleep 或者 lock 情況。

如果 t1 在執行的時候，遇到了 Sleep 或者 lock 鎖時需要被迫停止，此時系統會將 t1 線程送到 已暫停線程隊列 中，如果都 sleep 了，那 NumberOfConcurrentThreads 就會變為 0 ，此時就會遇到無人可用的情況，那怎麼辦呢？只能讓系統從 線程池 中申請更多的線程來從 q1 隊列中提取任務，當某個時刻， 已暫停線程隊列 中的線程激活，那麼它又回到了 已釋放隊列 中繼續執行任務，當任務執行完之後，再次調用 GetQueuedCompletionStatus 方法進去 等待線程隊列。

當然這裡有一個問題，某一個時刻 等待線程隊列 中的線程數會暫時性的超過 NumberOfConcurrentThreads 值，不過問題也不大。

說了這麼多理論是不是有點懵，沒關係，接下來我結合 windbg 和 coreclr 源碼一起看下。

以我的機器來說，IO完成端口內核對象 默認最多允許 12 個 running 線程，當遇到 sleep 時看看會不會突破 12 的限制，上代碼：


    class Program
    {
        static void Main(string[] args)
        {
            for (int i = 0; i < 2000; i++)
            {
                Task.Run(async () =>
                {
                    await GetString();
                });
            }

            Console.ReadLine();
        }

        public static int counter = 0;

        static async Task<string> GetString()
        {
            var httpClient = new HttpClient();

            var str = await httpClient.GetStringAsync("//cnblogs.com");

            Console.WriteLine($"counter={++counter}, 線程：{Thread.CurrentThread.ManagedThreadId},str.length={str.Length}");

            Thread.Sleep(1000000);

            return str;
        }
    }

從圖中看，已經破掉了 12 的限制，那是不是 30 呢？可以用 windbg 幫忙確認一下。


0:059> !tp
CPU utilization: 3%
Worker Thread: Total: 13 Running: 0 Idle: 13 MaxLimit: 2047 MinLimit: 12
Work Request in Queue: 0
--------------------------------------
Number of Timers: 1
--------------------------------------
Completion Port Thread:Total: 30 Free: 0 MaxFree: 24 CurrentLimit: 30 MaxLimit: 1000 MinLimit: 12

從最後一行看，沒毛病， IO完成端口線程 確實是 30 個。

在這種情況，異步操作一定會創建線程來處理

遇到耗時操作

所謂的耗時操作，大體上是大量的序列化，複雜計算等等，這裡我就用 while(true) 模擬，因為所有線程都沒有遇到暫停事件，所以理論上不會突破 12 的限制，接下來稍微修改一下 GetString() 方法。


        static async Task<string> GetString()
        {
            var httpClient = new HttpClient();

            var str = await httpClient.GetStringAsync("//cnblogs.com");

            Console.WriteLine($"counter={++counter},時間:{DateTime.Now}, 線程：{Thread.CurrentThread.ManagedThreadId},str.length={str.Length}");

            while (true) { }

            return str;
        }

對比圖中的時間，過了30s也無法突破 12 的限制，畢竟這些線程都是 running 狀態並都在 已釋放隊列中，這也就造成了所謂的 請求無響應 的尷尬情況。

二：直面問題

如果明白了上面我所說的，那麼 異步操作會不會創建線程？ 問題，我的答案是 有可能會也有可能不會，具體還是取決於上面提到了兩種 callback 邏輯。

Tags: C#遺忘系列 windbg