Какая польза от использования Executors только для потоков в программе Java.
Например,
ExecutorService pool = Executors.newFixedThreadPool(2);
void someMethod() {
//Thread
new Thread(new SomeRunnable()).start();
//vs
//Executor
pool.execute(new SomeRunnable());
}
Выполняет ли исполнитель просто ограничение количества потоков, которые он позволяет запускать сразу (пул потоков)? Разве это фактически мультиплексирует runnables на потоки, которые он создает вместо этого? Если нет, это просто способ избежать необходимости писать новый Thread (runnable).start() каждый раз?
Да, исполнители обычно будут мультиплексировать runnables на потоки, которые они создают; они будут ограничивать и управлять количеством потоков, запущенных одновременно; они упростят настройку уровней concurrency. Как правило, исполнители должны быть предпочтительнее, чем просто создавать голые потоки.
Создание новых потоков дорого. Поскольку Executors использует пул потоков, вы можете легко повторно использовать потоки, что приводит к лучшей производительности.
Выполняет ли исполнитель просто ограничение количества потоков, которые он позволяет запускать сразу (пул потоков)?
Executors#newFixedThreadPool(int), Executors#newSingleThreadExecutor сделать это, каждый под разными терминами (прочитайте соответствующий javadoc, чтобы узнать больше об этом).
Разве это фактически мультиплексирует runnables на потоки, которые он создает вместо?
Да
Если нет, это просто способ избежать необходимости писать новый Thread (runnable).start() каждый раз?
ExecutorService помогает вам контролировать способ обработки потоков. Конечно, вы можете сделать это вручную, но нет необходимости изобретать велосипед. Кроме того, существуют другие функции, которые ExecutorService предоставляет вам возможность выполнять асинхронные задачи с помощью Future экземпляров.
Существует несколько проблем, связанных с потоком.
Исполнители предоставляют различные виды реализации для создания пула потоков. Также создание потоков - дорогостоящее дело. Исполнители создают и управляют этими потоками внутренне. Подробности об этом можно найти в приведенной ниже ссылке. http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html
Как я уже говорил в связанном вопросе, Threads довольно плохи. Исполнители (и соответствующие классы concurrency) довольно хороши:
Предостережение: Вокруг здесь я категорически отвергаю использование необработанных потоков. я предпочитают использовать Callables и FutureTasks (из javadoc: "A отменяемое асинхронное вычисление" ). Интеграция тайм-аутов, правильная отмена и объединение потоков современного concurrencyподдержка для меня намного полезнее, чем груды необработанных потоков.
Например, я в настоящее время заменяю устаревшую часть кода, в которой используется непересекающийся поток, выполняющийся в цикле с автоспуском, чтобы определить, как долго он должен Thread.sleep() после каждой итерации. Моя замена будет использовать очень простой Runnable (для проведения одной итерации), ScheduledExecutorService для запуска одной из итераций и Future в результате метода scheduleAtAFixedRate для настройки времени между итерациями.
В то время как вы можете утверждать, что замена будет фактически эквивалентна устаревшему коду, я заменил бы тайный рычаг управления потоками и принятие желаемого за действительное с разделенным набором функций, который отделяет проблемы GUI (в настоящее время мы запускаем?) из обработки данных (воспроизведение со скоростью 5 раз) и управления файлами (отмените этот прогон и выберите другой файл).