Threadpool уже достаточно хорошо справляется с этой задачей. Он пытается ограничить количество запущенных потоков количеством ядер ЦП на вашем компьютере. Когда один поток заканчивается, он немедленно планирует другой подходящий поток для выполнения.
Каждые 0,5 секунды он оценивает, что происходит с запущенными потоками. Когда потоки выполняются слишком долго, он предполагает, что они остановились, и позволяет другому потоку начать выполнение. Теперь у вас будет больше потоков, чем у процессорных ядер. Это может доходить до максимального количества разрешенных потоков, как установлено ThreadPool.SetMaxThreads ().
Начиная с .NET 2.0 с пакетом обновления 1 (SP1), максимальное количество потоков по умолчанию было значительно увеличено в 250 раз по сравнению с количеством ядер. Вы никогда не должны туда добраться. Если вы это сделаете, вы бы потратили около 2 минут времени, когда выполнялось, возможно, неоптимальное количество потоков. Тем не менее, все эти потоки должны были бы блокироваться так долго, что не является типичным шаблоном выполнения для потока. С другой стороны, если все эти потоки ожидают одного и того же вида ресурса, они, вероятно, просто по очереди, добавление большего количества потоков не может улучшить пропускную способность.
Короче говоря, пул потоков будет работать хорошо, если вы запускаете потоки, которые выполняются быстро (не более секунды) и не блокируются в течение длительного времени. Возможно, вам следует подумать о создании собственных объектов Thread, если ваш код не соответствует этому шаблону.