Максимальное количество элементов в очереди в ThreadPool.QueueUserWorkItem

Это зависимый от реализации вопрос, а реализация этой функции немного изменилась с течением времени. Но в .NET 4.0 вы, по сути, ограничены количеством памяти в системе, поскольку задачи хранятся в очереди памяти. Вы можете увидеть это, копая реализацию в отражателе.

Из Документация ThreadPool :

Примечание: Темы в пуле управляемого потока - это фоновые потоки. То есть их свойства отблокировки верны. Это означает, что нить Threadpool не будет держать приложение, запущенное после того, как все потоки переднего плана вышли.

Возможно ли, что вы выходите, прежде чем все задачи были обработаны?

Если вам нужно ждать всех задач для обработки, вам нужно справиться с этим. Темы Threadpool - это все фоновые нити, и не сохранит приложение в живых.

Это относительно чистый способ справиться с этим типом ситуации:

 using (var mre = new ManualResetEvent(false))
 {
      int remainingToProcess = workItems.Count(); // Assuming workItems is a collection of "tasks"
      foreach(var item in workItems)
      {
           // Delegate closure (in C# 4 and earlier) below will 
           // capture a reference to 'item', resulting in
           // the incorrect item sent to ProcessTask each iteration.  Use a local copy
           // of the 'item' variable instead.
           // C# 5/VS2012 will not require the local here.
           var localItem = item;
           ThreadPool.QueueUserWorkItem(delegate
           {
               // Replace this with your "work"
               ProcessTask(localItem);

               // This will (safely) decrement the remaining count, and allow the main thread to continue when we're done
               if (Interlocked.Decrement(ref remainingToProcess) == 0)
                      mre.Set();
           });
      }
      mre.WaitOne();
 }

, которые говорят, что, как правило, лучше для «группировать» вместе вашим рабочим предметом, если у вас есть тысячи из них, и не относиться к ним как отдельные рабочие предметы для Threadpool. Это некоторые накладные расходы, участвующие в управлении списком элементов, и поскольку вы не сможете обрабатывать 22000 одновременно, вам лучше сгруппировать их в блоки. Наличие одиночных рабочих элементов каждый процесс 50 или около того, вероятно, поможет вашей общей пропускной способности довольно немного ...