私は、System.Threading.ThreadがIDisposableではなくファイナライザを実装していることに気付きました。推奨される方法は、ファイナライザが実装されているときに常にIDisposableを実装することです。 Jeffrey Richter wroteは、ガイドラインが「非常に重要であり、常に例外なく従うべきである」と指摘しています。スレッドがIDisposableを実装していないのはなぜですか？
スレッドはなぜIDisposableを実装していませんか？ IDisposableの実装は、Threadのファイナライズ可能なリソースの確定的なクリーンアップを可能にする重要な変更ではないようです。
関連する質問：スレッドはファイナライズ可能なので、実行中にスレッドがファイナライズされないようにするには、実行中のスレッドへの参照を保持する必要がありますか？
Threadオブジェクトを処分するとどうなりますか？この場合の「リソース」には、独自の自然クリーンアップ（スレッド終了）があります。オーナーシップ感覚が失われていることにも注意してください...実行中のスレッド内では常にThread.CurrentThreadを使用することができます。したがって、そのスレッドだけが本当にどんな種類の所有権も主張できます。
私は基本的にはThreadがちょっと変わったケースだと考えています。基本的なリソースには寿命がありますが、明示的にクリーンアップするべきではありません。
おそらく、スレッドのを処分できない可能性があります。代わりに、Abort()またはそれに類するものを使用して死ぬように求めることができます。
一般的に、Abortの使用は良い方法ではありません。スレッドメソッドが（ブールなどを使用して）返ってきて、残りの部分がクリアされるようにしてください。 –
これは設計上の問題です。だから、.NETのこの側面を構築することに関与していなかった人は推測できます。つまり、this blog postは良い点を作っています：
... IDisposableを実装すると、少なくともThreadの現在の実装では何の違いもありません。私は作成されているスレッドの数を増やし、ある時点でハンドルの数が少なくなるので、それらを閉じるためのメカニズムがいくつかあります。
スレッドは自然に処理しますので、管理する必要はありません典型的な意味で。
ManagedThreadIDは整数なので、スレッドが開始される前でも読み取ることができるので、スレッドが作成されたときに何かが割り当てられることを示唆します（番号自体であっても）。アプリケーションが2億のThreadsオブジェクトを作成することは奇妙なことですが、IDは解放に値するリソースであるように見えます。 – supercat
@supercat：興味深い点。 'ManagedThreadId'は順番に割り当てられているようです - あなたが20億人以上を作成した後に何が起こるのか分かりません。 –
Threadオブジェクトがファイナライズの対象となったときに、IDが再利用されるように見えるので、Threading.ThreadはIDIsposableではなくFinalizeを実装していると思われます。 – supercat