Это скорее проблема бизнеса.Допустим, я оператор связи.Я запрещаю своим абонентам совершать исходящие звонки, когда они не очищают свои взносы.Когда они делают платеж, я снимаю флажок, и через секунду абонент может совершать звонки.Но в моей системе происходит множество других действий, таких как обработка использования, выставление счетов, форматирование счетов и т. Д.
Теперь давайте предположим, что у меня есть общий пул потоков для всей системы, и я начал выставлять счета 50 000 подписчиков.Все мои потоки теперь обрабатывают относительно длительные платежные задания, и накапливается огромная очередь.
Бедный клиент сейчас делает платеж и хочет сделать срочный вызов.Но в моем пуле не осталось потока, чтобы очистить флаг.Клиенту пришлось ждать час, прежде чем он сможет сделать звонок.Это нарушение SLA.
Я должен был создать отдельные пулы потоков.Если задания по разблокировке вызовов не очень частые и короткие, я могу создать для них отдельный пул с размером ядра 5, может быть.Для биллинговых заданий я бы предпочел создать пул с размером ядра 25 и максимальным размером 30.
Итак, мои системные ограничения в любом случае не превысят, потому что я знаю, что даже в худшем случае у меня не будет большечем 30 потоков.
Это также облегчит отладку.Если у меня есть разные шаблоны имен потоков для каждого пула и в моей системе есть некоторые проблемы.Я легко могу сделать дамп потока и понять, является ли виновным факт оплаты или оплаты.
Итак, я думаю, что существующий дизайн основан на некотором бизнес-сценарии, который необходимо тщательно понять, прежде чем предлагать решение.