我注意到System.Threading.Thread實現了一個終結器，但不是IDisposable。推薦的做法是在實現終結器時始終實現IDisposable。 Jeffrey Richter wrote該準則是「非常重要，應該始終遵循」。爲什麼線程不執行IDisposable？
那麼，爲什麼不線程實現IDisposable？看起來實現IDisposable將是一個非破壞性的改變，它將允許確定性地清理Thread的可終止資源。
和相關的問題：因爲線程是終結，我必須保持引用正在運行的線程，以防止它們在執行過程中被敲定？
什麼將一個Thread對象的處置呢？這種情況下的「資源」有自己的自然清理 - 螺紋加工。請注意，所有權意識也缺失......在執行線程中，您始終可以使用Thread.CurrentThread，因此只有該線程才能真正聲明任何所有權。
基本上我認爲Thread是一個稍微不尋常的情況 - 底層資源有一生，但它不是應該明確清理的東西。
這可能是因爲你不能處理線程的。相反，你可以讓它使用Abort()或類似的東西去死。
您可以但通常使用Abort並不被認爲是好的做法 - 只要確保線程方法返回（使用bool或類似方法）並且系統清除其餘部分即可。 – 2009-11-11 17:53:35
這是怎樣的一個設計問題，所以任何人誰沒有參與構建.NET這方面只能猜測。也就是說，this blog post提供了一個很好的觀點：
...實現IDisposable不會有什麼區別，至少在Thread的當前實現中。我增加了正在創建的線程數和句柄計數下降在某些時候所以有一些機制來關閉它們
線程不自然清理後，所以他們並不需要被管理的資源在典型意義上說。
由於ManagedThreadID是一個整數，並且可以在線程啓動之前就被讀取，這將表明，事情是創建線程時被分配（哪怕只是數字本身）。雖然創建2億個線程對象的應用程序會很奇怪，但它似乎是一個可能值得釋放的資源。 – supercat 2010-12-22 16:39:55
@supercat：有趣的一點。 'ManagedThreadId'看起來是按順序分配的 - 我不知道在創建超過20億個後會發生什麼。 – 2010-12-22 16:46:51
當Thread對象有資格進行最終化時，id似乎會被重用，所以我懷疑Threading.Thread正在實現Finalize而不是IDIsposable。 – supercat 2010-12-22 16:58:02