为什么Thread没有实现IDisposable？

Question

我注意到 System.Threading.Thread 类实现了一个 finalizer（终结器），但没有实现 IDisposable 接口。推荐的做法是当实现 finalizer 时，总是应该同时实现 IDisposable 接口。Jeffrey Richter 写道，这个指导方针 "非常重要，应该始终无例外地遵循"。

那么为什么 Thread 没有实现 IDisposable 呢？似乎实现 IDisposable 不会造成破坏性的变化，反而能够允许 Thread 的 finalizable 资源进行确定性清理。

还有一个相关的问题：由于线程是可终结的，是否需要在执行过程中保持对正在运行的线程的引用，以防止它们在执行期间被终结？

- Special Touch

Answer 1

处理一个Thread对象会发生什么？在这种情况下，“资源”有自己的自然清理方式 - 线程完成。请注意，所有权感也缺失了...在执行线程内，您始终可以使用Thread.CurrentThread，因此只有那个线程才能真正声明任何形式的所有权。

基本上，我认为Thread是一个稍微不同寻常的案例 - 底层资源有一个生命周期，但它并不是应该显式清理的东西。

- Jon Skeet

---

由于ManagedThreadID是一个整数，并且可以在线程启动之前读取，这表明在创建线程时分配了某些东西（即使仅是数字本身）。虽然应用程序创建2亿个线程对象可能很奇怪，但看起来这些id可能是值得释放的资源。 - supercat

@supercat：很有意思的观点。 ManagedThreadId 似乎是按顺序分配的——我不知道在创建了超过 20 亿个之后会发生什么。 - Jon Skeet

当Thread对象变得可终结时，ID似乎会被重复使用，因此我怀疑Threading.Thread正在实现Finalize但不是IDisposable。 - supercat

我不确定这是否已经涵盖了它。在许多情况下，Thread与Process类似，因为它只是对本地资源（即操作系统线程）的句柄 - Process实现了IDisposable，那么为什么Thread没有呢？例如，两者都有终结器。 - Fowl

Answer 2

可能是因为你不能释放一个线程。相反，你可以使用 Abort() 或类似的方法请求终止它。

- Miguel Ventura

---

你可以这样做，但通常情况下使用Abort并不被认为是良好的实践 - 只需确保线程方法返回（使用bool或类似方式），系统会清理其余部分。 - Matt Breckon

Answer 3

这是一个设计问题，因此没有参与.NET此方面构建的人只能猜测。话虽如此，this blog post提出了一个很好的观点：

“... 实现IDisposable不会有任何区别，至少在Thread的当前实现中不会。 我增加了正在创建的线程数量，并且句柄计数在某个时候会下降，因此有一些机制可以关闭它们。”

线程自然会自我清理，因此它们不是需要以典型方式进行管理的资源。

- Rex M