When should we use Java's Thread over Executor?

Question

Executor seems like a clean abstraction. When would you want to use Thread directly rather than rely on the more robust executor?

Answer 1

java.util.concurrent package provides executor interface and can be used to created thread.

The Executor interface provides a single method, execute, designed to be a drop-in replacement for a common thread-creation idiom. If r is a Runnable object, and e is an Executor object you can replace

(new Thread(r)).start();

with

e.execute(r);

Refer here

Answer 2

There is no advantage to using raw threads. You can always supply Executors with a Thread factory, so even the option of custom thread creation is covered.

Answer 3

You don't use Thread unless you need more specific behaviour that is not found in Thread itself. You then extend Thread and add your specifically wanted behaviour.

Else just use Runnable or Executor.

Answer 4

To give some history, Executors were only added as part of the java standard in Java 1.5. So in some ways Executors can be seen as a new better abstraction for dealing with Runnable tasks.

A bit of an over-simplification coming... - Executors are threads done right so use them in preference.

Answer 5

It's always better to prefer Executor to Thread even for single thread as below

ExecutorService fixedThreadPool = Executors.newFixedThreadPool(1);

You can use Thread over Executor in below scenarios

1. Your application needs limited thread(s) and business logic is simple

2. If simple multi-threading model caters your requirement without Thread Pool

3. You are confident of managing thread(s) life cycle + exception handling scenarios with help of low level APIs in below areas : Inter thread communication, Exception handling, reincarnation of threads due to unexpected errors

and one last point

4. If your application does not need customization of various features of ThreadPoolExecutor

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

In all other cases, you can go for ThreadPoolExecutor

Answer 6

Well, I thought that a ThreadPoolExecutor provided better performance for it manages a pool of threads, minimizing the overhead of instantiating a new thread, allocating memory...

And if you are going to launch thousands of threads, it gives you some queuing functionality you would have to program by yourself...

Threads & Executors are different tools, used on different scenarios... As I see it, is like asking why should I use ArrayList when I can use HashMap? They are different...