В компьютерном программировании , пул потоков представляет собой шаблон проектирования программного обеспечения для достижения параллельности выполнения в компьютерной программе. Часто также называют реплицируются рабочие или рабоче-экипаж моделью , [1] пул потоков поддерживает несколько тема ждет задачи , которые будут выделены для параллельного исполнения контролирующей программы. Поддерживая пул потоков, модель увеличивает производительность и позволяет избежать задержек при выполнении из-за частого создания и уничтожения потоков для краткосрочных задач. [2] Количество доступных потоков настраивается на вычислительные ресурсы, доступные программе, такие как очередь параллельных задач после завершения выполнения.
Размер пула потоков - это количество потоков, хранящихся в резерве для выполнения задач. Обычно это настраиваемый параметр приложения, настроенный для оптимизации производительности программы. [3] Выбор оптимального размера пула потоков имеет решающее значение для оптимизации производительности.
Одно из преимуществ пула потоков перед созданием нового потока для каждой задачи состоит в том, что накладные расходы на создание и уничтожение потоков ограничиваются первоначальным созданием пула, что может привести к повышению производительности и стабильности системы . Создание и уничтожение потока и связанных с ним ресурсов может быть дорогостоящим процессом с точки зрения времени. Однако чрезмерное количество потоков в резерве расходует память, а переключение контекста между выполняемыми потоками приводит к снижению производительности. Соединение сокета с другим сетевым хостом, для разрыва и восстановления которого может потребоваться много циклов ЦП, можно поддерживать более эффективно, связывая его с потоком, который существует в течение более чем одной сетевой транзакции.
Использование пула потоков может быть полезно, даже если отложить время запуска потока. Существуют реализации пулов потоков, которые упрощают постановку работы в очередь, управление параллелизмом и синхронизацию потоков на более высоком уровне, чем это можно легко сделать при ручном управлении потоками. [4] [5] В этих случаях преимущества использования могут быть вторичными.
Обычно пул потоков выполняется на одном компьютере. Однако пулы потоков концептуально связаны с фермами серверов, в которых главный процесс, который сам может быть пулом потоков, распределяет задачи по рабочим процессам на разных компьютерах, чтобы увеличить общую пропускную способность. При таком подходе легко поддаются смущающе параллельные задачи. [ необходима цитата ]
Количество потоков может динамически регулироваться в течение срока службы приложения в зависимости от количества ожидающих задач. Например, веб-сервер может добавлять потоки, если поступают многочисленные запросы веб-страниц, и может удалять потоки, когда эти запросы сокращаются. [ спорно ] Стоимость большего пула потоков - увеличение использования ресурсов. Алгоритм, используемый для определения того, когда создавать или уничтожать потоки, влияет на общую производительность:
В Go мы работаем не с потоками, а с горутинами (более дешевыми, мультиплексированными в системные потоки), существует аналогичный шаблон «рабочий пул». [6] [7] [8]
Другой подход, который хорошо управляет ресурсами, состоит в том, чтобы запустить фиксированное количество горутин-дескрипторов, все считывающие из канала запроса. Количество горутин ограничивает количество одновременных вызовов для обработки
Когда дело доходит до вопроса о том, какие правильные конструкции для параллелизма язык должен предоставлять разработчикам, я искренне верю, что каналы и горутины Go настолько хороши, насколько это возможно.
Они обеспечивают хороший баланс между мощностью и гибкостью, одновременно избегая склонности к тупикам, которые вы наблюдаете в модели pthread, аду обслуживания, создаваемому обратными вызовами, или невероятным концептуальным накладным расходам обещаний.