我注意到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