2013-05-29 4 views
3

Может ли кто-нибудь рассказать мне пример реальной жизни, где удобно использовать этот заводский метод, а не другие?Примеры, когда удобно использовать Executors.newSingleThreadExecutor()

newSingleThreadExecutor

общественность статическая ExecutorService newSingleThreadExecutor()

Создает Исполнитель, который использует один рабочий поток, работающий от с неограниченной очереди. (Обратите внимание, что если этот единственный поток завершает из-за сбоя во время выполнения до выключения, новый будет займет свое место, если это необходимо для выполнения последующих задач.) Задачи гарантированно выполняются последовательно и не более одной задачи будет активным в любой момент времени. В отличие от эквивалентного в противном случае newFixedThreadPool (1) возвращенный исполнитель гарантированно не будет реконфигурируемый для использования дополнительных потоков.

Заранее спасибо.

ответ

12

Может ли кто-нибудь рассказать мне пример реальной жизни, где удобно использовать [фабричный метод newSingleThreadExecutor()], а не другие?

Я предполагаю, что вы спрашиваете, когда используете однопоточный пул потоков, а не пул фиксированных или кэшированных потоков.

Я использую однопоточный исполнитель, когда у меня много задач для запуска, но мне нужен только один поток. Это то же самое, что использовать фиксированный пул потоков 1, конечно. Часто это происходит из-за того, что нам не нужно, чтобы они запускались параллельно, это фоновые задачи, и мы не хотим использовать слишком много системных ресурсов (CPU, memory, IO). Я хочу иметь дело с различными задачами как Callable или Runnable объектов, поэтому ExecutorService является оптимальным, но все, что мне нужно, это один поток для их запуска.

Например, у меня есть несколько заданий таймера, которые я вставляю. У меня есть два типа задач, и мои «короткие» задачи выполняются в одном пуле потоков. Существует только один поток, который выполняет их все, хотя в моей системе есть несколько сотен. Они выполняют рутинные задачи, такие как проверка дискового пространства, очистка журналов, статистика демпинга и т. Д. Для задач, критически важных по времени, я запускаю пул кэшированных потоков.

Другим примером является то, что у нас есть ряд задач интеграции партнеров. Они не занимают очень много времени, и они работают довольно редко, и мы не хотим, чтобы они конкурировали с другими системными потоками, поэтому они запускались в одном поточном исполнителе.

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

+0

Зачем вам нужен только один поток? – Rollerball

+1

Потому что мы не хотим, чтобы они запускались параллельно и потребляли слишком много ресурсов процессора @Rollerball. Я добавил еще один пример, который показывает это. – Gray

+0

Спасибо, очень понятно. – Rollerball

0

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

2

Разница между Executors.newSingleThreadExecutor() и Executors.newFixedThreadPool(1) небольшая, но может быть полезна при разработке библиотечного API.Если вы выставите возвращаемый ExecutorService пользователям вашей библиотеки, и библиотека работает корректно только тогда, когда исполнитель использует один поток (задачи не являются потокобезопасными), предпочтительнее использовать Executors.newSingleThreadExecutor(). В противном случае пользователь вашей библиотеки может нарушить его, делая это:

ExecutorService e = myLibrary.getBackgroundTaskExecutor(); 
((ThreadPoolExecutor)e).setCorePoolSize(10); 

, что невозможно для Executors.newSingleThreadExecutor().

1

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

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