Один или несколько пулов потоков для сервера Java?

Я пишу довольно сложное серверное Java-приложение, которое имеет значительную часть фоновой обработки в дополнение к обычной обработке запроса-ответа. Часть фоновой обработки выполняется в стиле cron с использованием фреймворка Quartz. Другие задачи больше выполняются по запросу - если подключается новый клиент, он создает дополнительную работу для его обновления время от времени. Задачи cron также могут быть разнообразными — одни занимаются мониторингом внешних приложений, другие подсчитывают статистику и так далее.

Я использую несколько пулов потоков для запуска всех этих заданий с идеей, что похожие задания будут совместно использовать пул потоков, но разные задания не будут совместно использовать его. Например, задания мониторинга никогда не будут выполняться в пуле статистики, а задания статистики никогда не будут выполняться в пуле мониторов.

С другой стороны, я знаю, что некоторые люди предпочли бы просто иметь один пул потоков и запускать в нем все без какого-либо разделения.

Интересно, что считается лучшей практикой в ​​таком сценарии.

Каковы плюсы и минусы разделения пулов потоков?

Это даже имеет значение?


java multithreading threadpool
person Gregory Mostizky    schedule 17.09.2009    source источник

Ответы (2)


arrow_upward
6
arrow_downward

Ответ зависит от того, нужно ли вам разделять ресурсы приложения между различными типами активности или нет.

Например, в настоящее время я пишу серверное приложение, состоящее из нескольких высокопроизводительных модулей записи и потенциально большого количества читателей. Читатели будут обращаться к приложению спорадически, но потенциально могут запросить много данных (т. е. длительные запросы). Мне нужно убедиться, что писатели никогда не голодают, поэтому я собираюсь использовать в своем дизайне два пула потоков для чтения/записи. Если пул потоков чтения временно исчерпан, это не повлияет на писатели; только запросы на чтение будут задержаны.

Альтернативой было бы использование PriorityQueue в сочетании с ThreadPoolExecutor и присвоение более высокого приоритета запросам на запись.

Итак, в заключение. Мой совет: начните с одного пула потоков и усложняйте свой дизайн только в том случае, если для этого есть конкретная причина.

person Adamski    schedule 17.09.2009

arrow_upward
0
arrow_downward

На самом деле это не прямой ответ, а другое предложение :-(

Ваши задания Quartz можно приостанавливать, отменять и так далее, назовем это "управляемым". Я думаю, вы создадите некоторый пользовательский интерфейс для управления ими.

Вы понимаете, что другие ваши рабочие места («по запросу») не будут пользоваться теми же функциями, если вы, конечно, не реализуете их? Рассматривали ли вы возможность сделать все кварцеванием (даже если оно начнется немедленно), чтобы получить единый код?

person KLE    schedule 17.09.2009
comment
Собственно это один из вариантов. Однако есть две проблемы: одна из них заключается в том, что AFAIK Quartz заставляет использовать один пул потоков, в то время как я лично предпочитаю использовать несколько. Во-вторых, Quartz API отлично подходит для задач типа cron, но громоздкий, когда вам просто нужно быстро запустить какой-то алгоритм параллельно. - person Gregory Mostizky; 17.09.2009
comment
@Грегори, я понимаю вашу озабоченность по поводу номера пула потоков. У меня нет рекомендаций по этому поводу :-( Насчет громоздкого Quartz, именно так я себя чувствовал, когда работал с ним!! :-) Я инкапсулировал это в самодельный простой метод. - person KLE; 17.09.2009
comment
Честно говоря, у нас тоже проблемы с Quartz на кластере. Задание запускается где угодно, а не на сервере, обрабатывающем запрос. Я думаю, что Quartz запускается на первом запущенном узле, а другие узлы его не запускают. Это приводит к ряду проблем... - person KLE; 17.09.2009