Advantages of Executors over new Thread

Question

What benefit is there to use Executors over just Threads in a Java program.

Such as

ExecutorService pool = Executors.newFixedThreadPool(2);
void someMethod() {
    //Thread
    new Thread(new SomeRunnable()).start();

    //vs

    //Executor
    pool.execute(new SomeRunnable());
}

Does an executor just limit the number of threads it allows to have running at once (Thread Pooling)? Does it actually multiplex runnables onto the threads it creates instead? If not is it just a way to avoid having to write new Thread(runnable).start() every time?

"*..in large-scale applications, it makes sense to separate thread management and creation from the rest of the application. Objects that encapsulate these functions are known as executors.*" - [Source](http://docs.oracle.com/javase/tutorial/essential/concurrency/executors.html) — mre, Aug 28 '13 at 19:52
Nobody has yet answered "testing" - it's a lot easier (and quicker) to test with a stubbed implementation of ExecutorService that just calls run() on the Runnable within the current thread. (Though obviously you'd want to test the concurrent aspects too). Other considerations are; injection, container managed, configurable and monitoring. — earcam, Aug 28 '13 at 19:59

score 7 · Accepted Answer · answered Aug 28 '13 at 19:52

7

Yes, executors will generally multiplex runnables onto the threads they create; they'll constrain and manage the number of threads running at once; they'll make it much easier to customize concurrency levels. Generally, executors should be preferred over just creating bare threads.

answered Aug 28 '13 at 19:52

Louis Wasserman

191,574
25
345
413

Thanks. This was a good and quick answer. Multiplexing sells this for me, the thread limiter is just icing. – Chase Aug 28 '13 at 20:08

score 5 · Answer 2 · answered Aug 28 '13 at 19:54

5

Creating new threads is expensive. Because Executors uses a thread pool, you get to easily reuse threads, resulting in better performance.

answered Aug 28 '13 at 19:54

Blake Hood

314
3
12

Here are some [ballpark figures](http://stackoverflow.com/a/35667911/1143274) about the expense. This will help one judge whether refactoring an existing design using `Thread`s could result in any real better performance or is just a waste of time. – Evgeni Sergeev Feb 28 '16 at 07:54

score 2 · Answer 3 · answered Aug 28 '13 at 19:55

Does an executor just limit the number of threads it allows to have running at once (Thread Pooling)?

Executors#newFixedThreadPool(int), Executors#newSingleThreadExecutor do this, each one under different terms (read the proper javadoc to know more about it).

Does it actually multiplex runnables onto the threads it creates instead?

Yes

If not is it just a way to avoid having to write new Thread(runnable).start() every time?

ExecutorService helps you to control the way you handle threads. Of course, you can do this manually, but there's no need to reinvent the wheel. Also, there are other functionalities that ExecutorService provides you like executing asynchronous tasks through the usage of Future instances.

OP, note there are so many different `ExecutorService` implementations that you can use. — Sotirios Delimanolis, Aug 28 '13 at 19:59

score 0 · Answer 4 · answered Sep 02 '13 at 14:42

There are multiple concerns related to thread.

managing threads
resource utilization
creation of thread

Executors provides different kind of implementation for creating a pool of threads. Also thread creation is a costly affair. Executors creates and manages these threads internally. Details about it can be found in the below link. http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html

score -1 · Answer 5 · edited May 23 '17 at 12:26

As I said over in a related question, Threads are pretty bad. Executors (and the related concurrency classes) are pretty good:

Caveat: Around here, I strongly discourage the use of raw Threads. I much prefer the use of Callables and FutureTasks (From the javadoc: "A cancellable asynchronous computation"). The integration of timeouts, proper cancelling and the thread pooling of the modern concurrency support are all much more useful to me than piles of raw Threads.

For example, I'm currently replacing a legacy piece of code that used a disjoint Thread running in a loop with a self-timer to determine how long it should Thread.sleep() after each iteration. My replacement will use a very simple Runnable (to hold a single iteration), a ScheduledExecutorService to run one of the iterations and the Future resulting from the scheduleAtAFixedRate method to tune the timing between iterations.

While you could argue that replacement will be effectively equivalent to the legacy code, I'll have replaced an arcane snarl of Thread management and wishful thinking with a compartmentalized set of functionality that separates the concerns of the GUI (are we currently running?) from data processing (playback at 5x speed) and file management (cancel this run and choose another file).

Advantages of Executors over new Thread

5 Answers5

Linked