2012-01-12 2 views
1

У меня есть несколько асинхронных задач для параллельной работы. Все задачи можно разделить на два типа: позволяет вызывать один - тип A (который занимает много времени), а все остальное - тип B (быстрее и быстрее выполнять). с одним ScheduledThreadPoolExecutor с x-пулированием, в конце концов в какой-то момент все потоки заняты выполнением типа A, поскольку тип res B блокируется и задерживается. , что я пытаюсь выполнить, это запустить задачи типа A, параллельные типу B, и я хочу, чтобы задачи обоих типов запускались параллельно в своей группе для производительности.Запуск двух экземпляров ScheduledThreadPoolExecutor

Как вы думаете, было бы разумным иметь два экземпляра ScheduledThreadPoolExecutor для типов A и B исключительно с их собственными пулами потоков? Вы видите какие-либо проблемы с этим подходом?

ответ

1

Нет, это кажется разумным. Я делаю что-то подобное, то есть мне нужно выполнять задачи в серийном режиме в зависимости от некоторого id, например. все задачи, которые для компонента с id = "1" должны выполняться последовательно друг с другом и параллельно всем другим задачам, которые предназначены для компонентов с разными идентификаторами. , так что в основном мне нужна отдельная очередь задач для каждого другого компонента, задачи вытаскиваются один за другим из каждой конкретной очереди. Для того, чтобы добиться того, что я использую

Executors.newSingleThreadExecutor(new JobThreadFactory(componentId)); 

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

Executors.newFixedThreadPool(DEFAULT_THREAD_POOL_SIZE, new JobThreadFactory()); 

Это прекрасно работает для моего случая, по крайней мере. Единственная проблема, о которой я могу думать, если есть необходимость в упорядоченном выполнении задач, то есть task2 НУЖДЫ, которые будут выполняться после задачи1 и т. Д. Но я сомневаюсь, что здесь дело ...

+0

Звучит неплохо. В соответствии с вашими выборами, использующими использование Исполнителя, в отношении реализации, такой как ScheduledThreadPoolExecutor. любая конкретная причина? Также, что делает класс JobThreadFactory. (интересно, должно ли это быть saperate Qs?) – TechJack

+0

Я использую java.util.concurrent.Executors фабричные методы, потому что они защищают меня от сложных конструкторов конкретных реализаций ExecutorService. Например, фабричный метод newSingleThreadExecutor вызывает 6 параметров конструктора ThreadPoolExecutor ... Недостатком этого является то, что у вас нет контроля над импортом que, который используется для хранения ожидающих выполнения задач, и это может привести к некоторым утечкам памяти и т. Д. (если задачи выполняются медленнее, чем отправлены на исполнение). Фабрика может быть использована для именования потоков (как и я), запуск задачи запуска, конца и т. Д. ... – Svilen

Смежные вопросы