這個問題在微信上被別人問過好多次，想來想去覺得有必要統壹解答下，先說下我的答案： 可能會，也有可能不會 。
要想尋找答案，需要從 異步處理 的底層框架說起。
異步 從設計層面上來說它就是壹個 發布訂閱者 模式，畢竟它的底層用到了 端口完成隊列 ，可以從 IO完成端口內核對象 所提供的三個方法中有所體現。
可以粗看下簽名：
這個方法主要是將 文件句柄 和 IO完成端口內核對象 進行綁定，其中的 NumberOfConcurrentThreads 表示完成端口最多允許 running 的線程上限。
再看簽名：
這個函數的作用就是將壹個 包 通過 內核對象 丟給 驅動設備程序 ，由後者與硬件交互，比如 文件 。
看簽名：
這個方法嘗試從 IO完成端口內核對象 中提取 IO 包，如果沒有提取到，那麽就會無限期等待，直到提取為止。
對上面三個方法有了概念之後，接下來看下結構圖：
這張圖非常言簡意賅，不過只畫了 端口完成隊列 , 其實還有三個與IO線程有關的隊列，分別為： 等待線程隊列 ， 已釋放隊列 , 已暫停隊列 ，接下來我們稍微解讀壹下。
當 線程t1 調用 GetQueuedCompletionStatus 時，假使此刻 任務隊列q1 無任務， 那麽 t1 會卡住並自動進去 等待線程隊列 ，當某個時刻 q1 進了任務（由驅動程序投遞的），此時操作系統會將 t1 激活來提取 q1 的任務執行，同時將 t1 送到 已釋放隊列 中。
這個時候就有兩條路了。
如果 t1 在執行的時候，遇到了 Sleep 或者 lock 鎖時需要被迫停止，此時系統會將 t1 線程送到 已暫停線程隊列 中，如果都 sleep 了，那 NumberOfConcurrentThreads 就會變為 0 ，此時就會遇到無人可用的情況，那怎麽辦呢？只能讓系統從 線程池 中申請更多的線程來從 q1 隊列中提取任務，當某個時刻， 已暫停線程隊列 中的線程激活，那麽它又回到了 已釋放隊列 中繼續執行任務，當任務執行完之後，再次調用 GetQueuedCompletionStatus 方法進去 等待線程隊列 。
當然這裏有壹個問題，某壹個時刻 等待線程隊列 中的線程數會暫時性的超過 NumberOfConcurrentThreads 值，不過問題也不大。
說了這麽多理論是不是有點懵， 沒關系，接下來我結合 windbg 和 coreclr 源碼壹起看下。
以我的機器來說， IO完成端口內核對象 默認最多允許 12 個 running 線程，當遇到 sleep 時看看會不會突破 12 的限制，上代碼：
從圖中看，已經破掉了 12 的限制，那是不是 30 呢？ 可以用 windbg 幫忙確認壹下。
從最後壹行看，沒毛病， IO完成端口線程 確實是 30 個。
所謂的耗時操作，大體上是大量的序列化，復雜計算等等，這裏我就用 while(true) 模擬，因為所有線程都沒有遇到暫停事件，所以理論上不會突破 12 的限制，接下來稍微修改壹下 GetString() 方法。
對比圖中的時間，過了30s也無法突破 12 的限制，畢竟這些線程都是 running 狀態並都在 已釋放隊列 中，這也就造成了所謂的 請求無響應 的尷尬情況。
如果明白了上面我所說的，那麽 異步操作會不會創建線程 ？ 問題，我的答案是 有可能會也有可能不會 ，具體還是取決於上面提到了兩種 callback 邏輯。
本文來自blogs.com/huangxincheng/p/16085461.html