在異步處理程序中使用Threadpool.QueueWorkItem

Question

此異步處理程序的MSDN example使用ThreadPool.QueueUserWorkItem啓動新線程。

我認爲你不應該使用ThreadPool.QueueUserWorkItem來啓動新的線程，因爲線程是從ASP.net線程池中取得的，並且會破壞使用異步處理程序的目的。

這個例子錯了嗎？

Answer 1

有幾件事情錯了你的斷言：

• 當您使用ThreadPool.QueueUserWorkItem你不開始一個新的線程。這是讓ThreadPool擺在首位的關鍵。您正在重用池中的線程。
• 你在暗示這個例子是專門針對ASP.NET的，當它不是。它向您展示瞭如何使用ThreadPool來啓動後臺任務，而無需手動創建新線程（代價高昂）。確定何時以及何時不使用ThreadPool的工作仍然是您的工作。
• 使用ThreadPool運行異步任務不會「破壞使用異步處理程序的目的」。您使用異步處理程序的原因很多，包括在工作完成時不阻止用戶體驗，並利用機器可用的資源。
• 如果你正在做一個簡單的後臺任務，手動啓動另一個線程不會給你任何比使用ThreadPool更多的東西。如果你出於某種原因擔心你會以某種方式「捱餓」IIS的線程來處理接收到的請求，我想你會解除這個擔憂。在您的異步工作人員給您帶來問題之前，您的機器將會與交通癱瘓。
• 只是要清楚，如果你沒有運行ASP.NET應用程序，您自己的進程將有pool of it's own：

  當 執行的託管應用程序，運行時提供的 線程，這將是一個游泳池創建了代碼訪問它的第一個 時間。該池 與物理 過程，其中應用程序是運行 ，當你 使用可用的功能 在.NET基礎架構來運行 多個應用程序的一個重要的細節相關的（稱爲 應用程序域）同 過程中。如果是這種情況，則一個不好的 應用程序可能會影響其餘 以內的其他程序，因爲它們全都使用 相同的池。

  可以使用線程池或 通過 檢索有關它的信息類的線程池，在 的System.Threading命名空間。如果你 看看這個類，你會 看到所有的成員是靜態的 並沒有公共構造函數。 這是有道理的，因爲每個進程只有一個泳池 ，我們不能 創建一個新池。這 限制的目的是集中在同一 池中的所有 異步編程，這樣我們就沒有 第三方組件，創建一個 平行池，我們不能管理 ，其主題是降低我們的 性能。

所以不，這個例子沒有錯。這個例子非常好，並且精確地表明瞭它的意圖。