私は、しばらくしてアプリケーションの動作を停止したクライアントを支援しました (最終的には動作を再開しました)。
問題は、Task失敗したときにThread.Sleep（タスクで）5秒間使用されたことです。2 秒ごとに最大 800 のタスクがキューに入れられる可能性があるため、これらのジョブの多くが失敗して呼び出された場合の問題を想像できますThread.Sleep。それらのジョブはいずれも でマークされていませんでしたTaskCreationOptions.LongRunning。
私はタスクを書き直したので、Thread.Sleep（またはTask.Delayその点については）必須ではありませんでした。
TaskSchedulerただし、そのシナリオで（デフォルト）が何をしたかに興味があります。どのように、いつスレッド数を増やしますか?
MSDNによると
バックグラウンドで、タスクは ThreadPool のキューに入れられます。ThreadPool は、スループットを最大化するスレッド数を決定して調整するアルゴリズム (山登り法など) で強化されています。
ThreadPoolには、環境に応じてスレッドの最大数があります。より多くの を作成するTaskと、プールはスレッドの最大数に達するまでそれらを同時に実行できます。その時点で、それ以上のタスクはキューに入れられます。
ThreadPool使用できるスレッドの最大数を知りたい場合System.Threading.ThreadPool.GetMaxThreads(2 つの out int パラメーターを渡す必要があります。1 つはワーカー スレッドの最大数が入力され、もう 1 つは非同期 I の最大数が入力されます。 /O スレッド)。
実行時にアプリケーションで何が起こっているかをよりよく理解したい場合は、 [デバッグ] -> [ウィンドウ] -> [スレッド] に移動してVisual Studio のスレッド ウィンドウを使用できます(エントリはデバッグ中にのみ存在するため、最初にアプリケーションにブレークポイントを設定します)。
この投稿はおそらく興味深いものです。を使用しない限り、デフォルトのタスクスケジューラは単にタスクを ThreadPool のキューに入れるように見えますTaskCreationOptions.LongRunning。これは、ThreadPoolいつ新しいスレッドを作成するかを決定するのは に任されていることを意味します。