Microsoft のドキュメントから引用:
デフォルトでは、スレッド プールには、使用可能なプロセッサごとに 250 のワーカー スレッドがあります。この設定は、ThreadPool.SetMaxThreads メソッドを使用して変更できます。
また、広く知られているように、オーバーヘッドがあるとも言われています。
スレッドには、ある程度のオーバーヘッドがあります。したがって、コンピューターに複数のプロセッサがあり、処理を 2 つのスレッドに分割しても、パフォーマンスが 100% 向上することはありません。
いくつかの経験と推測から、私は250ではなく、CPU あたり1 から 4のスレッドのようなものを持っていたでしょう! 誰かがなぜ250か知っていますか？それは最高の全体的なパフォーマンスを提供するはずの値ですか、それとも他のタスクが完了するのを待たずにそのスレッドプールに与えるほとんどすべてのタスクを処理するためですか?
動機はパフォーマンスではありません。前述のように、スレッドが多すぎると、パフォーマンスが低下しやすくなります (コンテキストの切り替え、キャッシュのスラッシング、競合などによる)。
この魔法の数の背後にある考え方は、ユーザーのコードにデッドロックが発生するのを回避しようとする試みです。開発者がスレッド プールに多数の作業項目をキューに入れ、スレッド プールにキューに入れられていた他の項目も待機している場合、デッドロックが発生する可能性があります。スレッド プールが最大数のスレッドを使用している (すべてのスレッドが Wait 状態である) 状況が発生した場合は、デッドロックが発生しています。
もちろん、「250」という数字に特別なことはありません。開発者がこのような問題のあるスレッド プールの使用パターンを使用することに固執すると、デッドロックが発生する可能性があります。ただし、そのようなシナリオでデッドロックに達する可能性を減らす必要があります。
Joe Duffy は、彼の投稿でこの理由をより深く説明しています: CLR 2.0 SP1 のスレッドプールの既定の最大スレッド数が 250/CPU に増加した理由。