Подтвердить что ты не робот

Когда мы должны использовать Java Thread над Executor?

Исполнитель выглядит как чистая абстракция. Когда вы хотите использовать Thread напрямую, а не полагаться на более надежного исполнителя?

4b9b3361

Ответ 1

Чтобы дать некоторую историю, исполнители были добавлены только как часть стандарта Java в Java 1.5. Таким образом, в некотором смысле Executors можно рассматривать как новую лучшую абстракцию для решения задач Runnable.

Немного о чрезмерном упрощении... - Исполнители - это потоки, сделанные правильно, поэтому используйте их в предпочтении.

Ответ 2

Я использую Thread, когда мне нужна обработка сообщений на основе pull. Например. Очередь принимает() - en в цикле в отдельном потоке. Например, вы переносите очередь в дорогостоящем контексте - скажем, соединение JDBC, соединение JMS, файлы для обработки с одного диска и т.д.

Прежде чем я получу проклятие, есть ли у вас сценарий?

Изменить:

Как указано другими, интерфейс Executor (ExecutorService) имеет больший потенциал, так как вы можете использовать Executors для выбора поведения: запланированного, приоритетного, кэшированного и т.д. в Java 5+ или juc backport для Java 1.4.

Рамка-исполнитель имеет защиту от разбитых runnables и автоматически воссоздает рабочие потоки. Один из недостатков, на мой взгляд, заключается в том, что перед тем, как выйти из приложения, вы должны явно указать shutdown() и awaitTermination(), что не так просто в приложениях с графическим интерфейсом. Если вы используете ограниченные очереди, вам нужно указать a RejectedExecutionHandler или удалить новые runnables.

Вы можете взглянуть на Brian Goetz и др.: Java Concurrency на практике (2006)

Ответ 3

Нет смысла использовать необработанные потоки. Вы всегда можете поставлять исполнителям Thread factory, поэтому даже возможность создания пользовательских потоков закрывается.

Ответ 4

Вы не используете Thread, если вам не требуется более специфическое поведение, которое не встречается в самом потоке. Затем вы расширяете Thread и добавляете ваше особое желание.

Просто используйте Runnable или Executor.

Ответ 5

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

И если вы собираетесь запускать тысячи потоков, это дает вам некоторые функции очередей, которые вам придется программировать самостоятельно...

Threads and Executors - это разные инструменты, используемые в разных сценариях... Как я вижу, это похоже на вопрос, почему я должен использовать ArrayList, когда могу использовать HashMap? Они разные...

Ответ 6

java.util.concurrent пакет предоставляет интерфейс исполнителя и может использоваться для создания потока.

Интерфейс Executor предоставляет единственный метод, исполняемый, предназначенный для замены для общей идиомы создания потоков. Если r - объект Runnable, а e - объект Executor, вы можете заменить

(новая тема (r)). start();

с

e.execute(г);

Обратитесь здесь

Ответ 7

Всегда лучше отдавать предпочтение Executor до Thread даже для одного потока, как показано ниже

ExecutorService fixedThreadPool = Executors.newFixedThreadPool(1);

Вы можете использовать Thread более Executor в следующих сценариях

  • Ваше приложение нуждается в ограниченных потоках, а бизнес-логика проста

  • Если простая многопоточная модель удовлетворяет вашим требованиям без пула потоков

  • Вы уверены в том, что управляете сценариями жизненного цикла жизненных циклов или сценариев с использованием API низкого уровня в нижележащих областях: Inter thread communication, Exception handling, reincarnation of threads из-за непредвиденных ошибок

и одна последняя точка

  1. Если ваше приложение не нуждается в настройке различных функций ThreadPoolExecutor

    ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, 
    TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory, 
    RejectedExecutionHandler handler)
    

Во всех остальных случаях вы можете перейти на ThreadPoolExecutor