かなり前から使用されている .NET 4.0 Windows サービスがあります。Windows サービスは、基本的にバックグラウンド スレッドを使用して多くのファイルを処理します。ThreadPool クラスを使用し、Thread クラスは使用しません。Windows サービスのパフォーマンスが低下し始めたとき、私たちが行った手順の 1 つは、DebugDiag を使用してプロセスのダンプを取得することでした。レポートは、プロセスにデッド スレッドがあることを示していました。デッド スレッドの数も各ダンプによって異なります。
いくつかの調査の結果、デッド スレッドは、基になるネイティブ スレッドが存在しないマネージド スレッド オブジェクトであると説明するエントリに出会いました。これらのデッド スレッドは、ThreadPool 内のマネージド スレッドにすぎない可能性はありますか? もしそうなら、なぜ ThreadPool はすでに死んでいるスレッドを管理しているのでしょうか。
デッド スレッドの原因をさらに調査するために、空の Windows サービスのダンプを分析してみました。この演習では、レポートに 3 つのデッド スレッドが常に表示されました。使用した Windows サービスは、Visual Studio 2012 を使用して作成された既定の Windows サービスであり、ユーザー コード、空白の OnStart メソッドと OnStop メソッド、ファイナライザー、および VS2012 によって追加されたもの以外の追加のライブラリ参照はありません。
デッド スレッドに関する主な懸念事項は次のとおりです。 - これらのデッド スレッドは、どの .NET Windows サービスでも正常ですか。- 通常デッド スレッドの原因は何ですか? - デッド スレッドはメモリ リークを引き起こしますか? - デッド スレッドによって CPU が十分に活用されていませんか? - これらのデッドスレッドについてまったく心配する必要がありますか?