What is the advantage of using `ExecutorService` over running threads passing a `Runnable` into the `Thread` constructor?

What are the advantages of using an ExecutorService?

Since use `ExecutorService` can `submit` a `Callable` task and return a `Future`, why need to use `FutureTask` to wrap `Callable` task and use the method `execute`? I feel they both do the same thing.

What&#39;s the difference between Future and FutureTask in Java?

I have code where I schedule a task using `java.util.Timer`. I was looking around and saw `ExecutorService` can do the same. So this question here, have you used `Timer` and `ExecutorService` to schedule tasks, what is the benefit of one using over another?

Also wanted to check if anyone had used the `Timer` class and ran into any issues which the `ExecutorService` solved for them.

Java Timer vs ExecutorService?

Whenever I call `shutdownNow()` or `shutdown()` it doesn&#39;t shut down. I read of a few threads where it said that shutting down is not guaranteed - can someone provide me a good way of doing it?

How to shutdown an ExecutorService?

I have a method that performs some task with a timeout. I use the ExecutorServer.submit() to get a Future object, and then I call future.get() with a timeout. This is working fine, but my question is the best way to handle checked exceptions that can be thrown by my task. The following code works, and preserves the checked exceptions, but it seems extremely clumsy and prone to break if the list of checked exceptions in the method signature changes.

Any suggestions on how to fix this? I need to target Java 5, but I&#39;d also be curious to know if there are good solutions in newer versions of Java.

	public static byte[] doSomethingWithTimeout( int timeout ) throws ProcessExecutionException, InterruptedException, IOException, TimeoutException {

		Callable&lt;byte[]&gt; callable = new Callable&lt;byte[]&gt;() {
			public byte[] call() throws IOException, InterruptedException, ProcessExecutionException {
				//Do some work that could throw one of these exceptions
				return null;
			}
		};

		try {
			ExecutorService service = Executors.newSingleThreadExecutor();
			try {
				Future&lt;byte[]&gt; future = service.submit( callable );
				return future.get( timeout, TimeUnit.MILLISECONDS );
			} finally {
				service.shutdown();
			}
		} catch( Throwable t ) { //Exception handling of nested exceptions is painfully clumsy in Java
			if( t instanceof ExecutionException ) {
				t = t.getCause();
			}
			if( t instanceof ProcessExecutionException ) {
				throw (ProcessExecutionException)t;
			} else if( t instanceof InterruptedException ) {
				throw (InterruptedException)t;
			} else if( t instanceof IOException ) {
				throw (IOException)t;
			} else if( t instanceof TimeoutException ) {
				throw (TimeoutException)t;
			} else if( t instanceof Error ) {
				throw (Error)t;
			} else if( t instanceof RuntimeException) {
				throw (RuntimeException)t;
			} else {
				throw new RuntimeException( t );
			}
		}
	}

=== UPDATE ===

Many people posted responses that recommended either 1) re-throwing as a general exception, or 2) re-throw as an unchecked exception. I don&#39;t want to do either of these, because these exception types (ProcessExecutionException, InterruptedException, IOException, TimeoutException) are important - they will each be handled differently by the calling processed. If I were not needing a timeout feature, then I would want my method to throw these 4 specific exception types (well, except for TimeoutException). I don&#39;t think that adding a timeout feature should change my method signature to throw a generic Exception type.

What is the best way to handle an ExecutionException?

Let&#39;s say I have an application that utilizes the `Executor` framework as such

    Executors.newSingleThreadExecutor().submit(new Runnable(){
        @Override
        public void run(){
            // do stuff
        }
    }

When I run this application in the debugger, a thread is created with the following (default) name: `Thread[pool-1-thread-1]`. As you can see, this isn&#39;t terribly useful and as far as I can tell, the `Executor` framework does not provide an easy way to name the created threads or thread-pools.

So, how does one go about providing names for the threads/thread-pools? For instance, `Thread[FooPool-FooThread]`.

Naming threads and thread-pools of ExecutorService

What is the simplest way to to wait for all tasks of `ExecutorService` to finish? My task is primarily computational, so I just want to run a large number of jobs - one on each core.  Right now my setup looks like this: 

    ExecutorService es = Executors.newFixedThreadPool(2);
    for (DataTable singleTable : uniquePhrases) {	
        es.execute(new ComputeDTask(singleTable));
    }
    try{
        es.wait();
    } 
    catch (InterruptedException e){
        e.printStackTrace();
    }

`ComputeDTask` implements runnable.  This appears to execute the tasks correctly, but the code crashes on `wait()` with `IllegalMonitorStateException`.  This is odd, because I played around with some toy examples and it appeared to work.  

`uniquePhrases` contains several tens of thousands of elements.  Should I be using another method?  I am looking for something as simple as possible

ExecutorService, how to wait for all tasks to finish

I&#39;m trying to use Java&#39;s `ThreadPoolExecutor` class to run a large number of heavy weight tasks with a fixed number of threads. Each of the tasks has many places during which it may fail due to exceptions.

I&#39;ve subclassed `ThreadPoolExecutor` and I&#39;ve overridden the `afterExecute` method which is supposed to provide any uncaught exceptions encountered while running a task. However, I can&#39;t seem to make it work.

For example:

    public class ThreadPoolErrors extends ThreadPoolExecutor {
    	public ThreadPoolErrors() {
    		super(	1, // core threads
    				1, // max threads
    				1, // timeout
    				TimeUnit.MINUTES, // timeout units
    				new LinkedBlockingQueue&lt;Runnable&gt;() // work queue
    		);
    	}
    	
    	protected void afterExecute(Runnable r, Throwable t) {
    		super.afterExecute(r, t);
    		if(t != null) {
    			System.out.println(&quot;Got an error: &quot; + t);
    		} else {
    			System.out.println(&quot;Everything&#39;s fine--situation normal!&quot;);
    		}
    	}
    	
    	public static void main( String [] args) {
    		ThreadPoolErrors threadPool = new ThreadPoolErrors();
    		threadPool.submit( 
    				new Runnable() {
    					public void run() {
    						throw new RuntimeException(&quot;Ouch! Got an error.&quot;);
    					}
    				}
    		);
    		threadPool.shutdown();
    	}
    }

The output from this program is &quot;Everything&#39;s fine--situation normal!&quot; even though the only Runnable submitted to the thread pool throws an exception. Any clue to what&#39;s going on here?

Thanks!

Handling exceptions from Java ExecutorService tasks

How should I choose between **ExecutorService&#39;s** [submit][1] or [execute][2], if the returned value is not my concern? 

If I test both, I didn&#39;t see any differences among the two except the returned value.

    ExecutorService threadExecutor = Executors.newSingleThreadExecutor();
    threadExecutor.execute(new Task());


----------


    ExecutorService threadExecutor = Executors.newSingleThreadExecutor();
    threadExecutor.submit(new Task());

  [1]: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html#submit-java.util.concurrent.Callable-

  [2]: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executor.html#execute-java.lang.Runnable-

Choose between ExecutorService&#39;s submit and ExecutorService&#39;s execute

[`newCachedThreadPool()`][1] versus [`newFixedThreadPool()`][2]
  
When should I use one or the other? Which strategy is better in terms of resource utilization?


  [1]: http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool--
  [2]: http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html#newFixedThreadPool-int-

Executors.newCachedThreadPool() versus Executors.newFixedThreadPool()

I have a fixed thread pool that I submit tasks to (limited to **5** threads). How can I find out which one of those **5** threads executes my task (something like &quot;thread #3 of **5** is doing this task&quot;)?

    ExecutorService taskExecutor = Executors.newFixedThreadPool(5);
    
    //in infinite loop:
    taskExecutor.execute(new MyTask());
    ....
    
    private class MyTask implements Runnable {
    	public void run() {
    		logger.debug(&quot;Thread # XXX is doing this task&quot;);//how to get thread id?
    	}
    }

How to get thread id from a thread pool?

It seems to be impossible to make a cached thread pool with a limit to the number of threads that it can create.

Here is how static `Executors.newCachedThreadPool` is implemented in the standard Java library:

     public static ExecutorService newCachedThreadPool() {
        return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                      60L, TimeUnit.SECONDS,
                                      new SynchronousQueue&lt;Runnable&gt;());
    }

So, using that template to go on to create a fixed sized cached thread pool:

    new ThreadPoolExecutor(0, 3, 60L, TimeUnit.SECONDS, new SynchronusQueue&lt;Runable&gt;());

Now if you use this and submit 3 tasks, everything will be fine.  Submitting any further tasks will result in rejected execution exceptions.

Trying this:

    new ThreadPoolExecutor(0, 3, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue&lt;Runable&gt;());

Will result in all threads executing sequentially.  I.e., the thread pool will never make more than one thread to handle your tasks.

This is a bug in the execute method of `ThreadPoolExecutor`?  Or maybe this is intentional?  Or there is some other way?

Edit: I want something exactly like the cached thread pool (it creates threads on demand and then kills them after some timeout) but with a limit on the number of threads that it can create and the ability to continue to queue additional tasks once it has hit its thread limit.  According to sjlee&#39;s response this is impossible.  Looking at the `execute()` method of `ThreadPoolExecutor` it is indeed impossible.  I would need to subclass `ThreadPoolExecutor` and override `execute()` somewhat like `SwingWorker` does, but what `SwingWorker` does in its `execute()` is a complete hack.

Impossible to make a cached thread pool with a size limit?

I&#39;m looking for an [ExecutorService][1] implementation that can be provided with a timeout. Tasks that are submitted to the ExecutorService are interrupted if they take longer than the timeout to run. Implementing such a beast isn&#39;t such a difficult task, but I&#39;m wondering if anybody knows of an existing implementation.

Here&#39;s what I came up with based on some of the discussion below. Any comments?

    import java.util.List;
    import java.util.concurrent.*;

    public class TimeoutThreadPoolExecutor extends ThreadPoolExecutor {
        private final long timeout;
        private final TimeUnit timeoutUnit;
	
        private final ScheduledExecutorService timeoutExecutor = Executors.newSingleThreadScheduledExecutor();
        private final ConcurrentMap&lt;Runnable, ScheduledFuture&gt; runningTasks = new ConcurrentHashMap&lt;Runnable, ScheduledFuture&gt;();

        public TimeoutThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue&lt;Runnable&gt; workQueue, long timeout, TimeUnit timeoutUnit) {
            super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue);
            this.timeout = timeout;
            this.timeoutUnit = timeoutUnit;
        }

        public TimeoutThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue&lt;Runnable&gt; workQueue, ThreadFactory threadFactory, long timeout, TimeUnit timeoutUnit) {
            super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory);
            this.timeout = timeout;
            this.timeoutUnit = timeoutUnit;
        }

        public TimeoutThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue&lt;Runnable&gt; workQueue, RejectedExecutionHandler handler, long timeout, TimeUnit timeoutUnit) {
            super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, handler);
            this.timeout = timeout;
            this.timeoutUnit = timeoutUnit;
        }

        public TimeoutThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue&lt;Runnable&gt; workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler, long timeout, TimeUnit timeoutUnit) {
            super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory, handler);
            this.timeout = timeout;
            this.timeoutUnit = timeoutUnit;
        }

        @Override
        public void shutdown() {
            timeoutExecutor.shutdown();
            super.shutdown();
        }

        @Override
        public List&lt;Runnable&gt; shutdownNow() {
            timeoutExecutor.shutdownNow();
            return super.shutdownNow();
        }

        @Override
        protected void beforeExecute(Thread t, Runnable r) {
            if(timeout &gt; 0) {
                final ScheduledFuture&lt;?&gt; scheduled = timeoutExecutor.schedule(new TimeoutTask(t), timeout, timeoutUnit);
                runningTasks.put(r, scheduled);
            }
        }

        @Override
        protected void afterExecute(Runnable r, Throwable t) {
            ScheduledFuture timeoutTask = runningTasks.remove(r);
            if(timeoutTask != null) {
                timeoutTask.cancel(false);
            }
        }

        class TimeoutTask implements Runnable {
            private final Thread thread;

            public TimeoutTask(Thread thread) {
                this.thread = thread;
            }

            @Override
            public void run() {
                thread.interrupt();
            }
        }
    }

  [1]: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ExecutorService.html

ExecutorService that interrupts tasks after a timeout

I have a program that spawns threads (~5-150) which perform a bunch of tasks. Originally, I used a `FixedThreadPool` because [this similar question][1] suggested they were better suited for longer lived tasks and with my very limited knowledge of multithreading, I considered the average life of the threads (several minutes) &quot;*long lived*&quot;.

However, I recently added the capability to spawn additional threads and doing so takes me above the thread limit I set. In this case, would it be better to guess and increase the number threads I can allow or to switch to a `CachedThreadPool` so I have no wasted threads?

Trying them both out preliminarily, there doesn&#39;t *seem* to be a difference so I&#39;m inclined to go with the `CachedThreadPool` just to avoid the waste. However, does the life span of the threads mean I should instead picked a `FixedThreadPool` and just deal with the unused threads? [This question][2] makes it seem like those extra threads aren&#39;t wasted but I would appreciate the clarification.

  [1]: https://stackoverflow.com/questions/949355/newcachedthreadpool-v-s-newfixedthreadpool
  [2]: https://stackoverflow.com/questions/13110313/java-fixedthreadpool-with-known-pool-size-but-unknown-workers


FixedThreadPool vs CachedThreadPool: the lesser of two evils

I was reading about it quite a bit in the past couple of hours, and I simply cannot see any reason (**valid** reason) to call `shutdown()` on the `ExecutorService`, unless we have a humongous application that stores, dozens and dozens of different executor services that are not used for a long time.

The only thing (from what I gather) the shutdown does, is doing what a normal Thread does once it&#39;s done. When the normal Thread will finish the run method of the Runnable(or Callable), it will be passed to Garbage Collection to be collected. With Executor Service the threads will simply be put on hold, they will not be ticked for the garbage collection. For that, the shutdown is needed.

Ok back to my question. Is there any reason to call shutdown on `ExecutorService` very often, or even right after submitting to it some tasks? I would like to leave behind the case someone is doing it and right after that calls to `awaitTermination()` as this is validated. Once we do that, we have to recreate a new `ExecutorService` all over again, to do the same thing. Isn&#39;t the whole idea for the `ExecutorService` to reuse the threads? So why destroy the `ExecutorService` so soon?

Isn&#39;t it a rational way to simply create `ExecutorService` (or couple depending on how many you need), then during the application running pass to them the tasks once they come along, and then on the application exit or some other important stages shutdown those executors?

I&#39;d like an answer from some experienced coders who do write a lot of asynchronous code using the ExecutorServices.

Second side question, a bit smaller deals with the android platform. IF some of you will say that it&#39;s not the best idea to shutdown executors every time, and your program on android, could you tell me how do you handle those shutdowns (to be specific - when you execute them) when we deal with different events of the application life cycle.

Because of the CommonsWare comment, I made the post neutral. I really am not interested in arguing about it to death and it seems it&#39;s leading there. I&#39;m only interested in learning about what I asked here from experienced developers if they are willing to share their experiences. Thanks.

Reason for calling shutdown() on ExecutorService

I am learning to use `ExectorService` to pool `threads` and send out tasks. I have a simple program below

```
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;


class Processor implements Runnable {

    private int id;

    public Processor(int id) {
        this.id = id;
    }

    public void run() {
        System.out.println(&quot;Starting: &quot; + id);

        try {
            Thread.sleep(5000);
        } catch (InterruptedException e) {
            System.out.println(&quot;sorry, being interupted, good bye!&quot;);
            System.out.println(&quot;Interrupted &quot; + Thread.currentThread().getName());
            e.printStackTrace();
        }

        System.out.println(&quot;Completed: &quot; + id);
    }
}


public class ExecutorExample {

    public static void main(String[] args) {
        Boolean isCompleted = false;

        ExecutorService executor = Executors.newFixedThreadPool(2);

        for (int i = 0; i &lt; 5; i++) {
            executor.execute(new Processor(i));
        }

        //executor does not accept any more tasks but the submitted tasks continue
        executor.shutdown();

        System.out.println(&quot;All tasks submitted.&quot;);

        try {
            //wait for the exectutor to terminate normally, which will return true
            //if timeout happens, returns false, but this does NOT interrupt the threads
            isCompleted = executor.awaitTermination(100, TimeUnit.SECONDS);
            //this will interrupt thread it manages. catch the interrupted exception in the threads
            //If not, threads will run forever and executor will never be able to shutdown.
            executor.shutdownNow();
        } catch (InterruptedException e) {
        }

        if (isCompleted) {
            System.out.println(&quot;All tasks completed.&quot;);
        } else {
            System.out.println(&quot;Timeout &quot; + Thread.currentThread().getName());
        }
    }
}
```

It does nothing fancy, but creates two `threads` and submits 5 tasks in total. After each `thread` completes its task, it takes the next one,
In the code above, I use `executor.submit`. I also changed to `executor.execute`. But I do not see any difference in the output. In what way are the `submit` and `execute` methods different?
This what the `API` says

&gt; Method submit extends base method Executor.execute(java.lang.Runnable) by creating and returning a Future that can be used to cancel execution and/or wait for completion. Methods invokeAny and invokeAll perform the most commonly useful forms of bulk execution, executing a collection of tasks and then waiting for at least one, or all, to complete. (Class ExecutorCompletionService can be used to write customized variants of these methods.)

But it&#39;s not clear to me as what it exactly means?

What is the difference between ExecutorService.submit and ExecutorService.execute in this code in Java?

I am trying to code a solution in which a single thread produces I/O-intensive tasks that can be performed in parallel. Each task have significant in-memory data. So I want to be able limit the number of tasks that are pending at a moment. 

If I create ThreadPoolExecutor like this:

        ThreadPoolExecutor executor = new ThreadPoolExecutor(numWorkerThreads, numWorkerThreads,
                                      0L, TimeUnit.MILLISECONDS,
                                      new LinkedBlockingQueue&lt;Runnable&gt;(maxQueue));



Then the `executor.submit(callable)` throws `RejectedExecutionException` when the queue fills up and all the threads are already busy. 

What can I do to make `executor.submit(callable)` block when the queue is full and all threads are busy?

**EDIT**:
I tried [this][1]:

    executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());

And it somewhat achieves the effect that I want achieved but in an inelegant way (basically rejected threads are run in the calling thread, so this blocks the calling thread from submitting more).

**EDIT: (5 years after asking the question)**

To anyone reading this question and its answers, please don&#39;t take the accepted answer as one correct solution. Please read through all answers and comments.


  [1]: https://stackoverflow.com/a/5656329/32453

Java: ExecutorService that blocks on submission after a certain queue size

I am using an ExecutoreService in Java 1.6, started simply by 

	ExecutorService pool = Executors.newFixedThreadPool(THREADS). 

When my main thread is finished (along with all the tasks processed by the thread pool), this pool will prevent my program from shutting down until I explicitly call

	pool.shutdown();

Can I avoid having to call this by somehow turning the internal thread managing used by this pool into a deamon thread? Or am I missing something here.

Turning an ExecutorService to daemon in Java

I need to execute some amount of tasks 4 at a time, something like this:

    ExecutorService taskExecutor = Executors.newFixedThreadPool(4);
    while(...) {
    	taskExecutor.execute(new MyTask());
    }
    //...wait for completion somehow

How can I get notified once all of them are complete? For now I can&#39;t think about anything better than setting some global task counter and decrease it at the end of every task, then monitor in infinite loop this counter to become 0; or get a list of Futures and in infinite loop monitor isDone for all of them. What are better solutions not involving infinite loops?

Thanks.


  [1]: http://stackoverflow.com/questions/702415/how-to-know-if-other-threads-have-finished

How to wait for all threads to finish, using ExecutorService?

Does the `ExecutorService` guarantee thread safety ? 

I&#39;ll be submitting jobs from different threads to the same ThreadPoolExecutor, do I have to synchronize access to the executor before interacting/submitting tasks?


Is ExecutorService (specifically ThreadPoolExecutor) thread safe?

Please read the question carefully before marking this as duplicate. 

Below is the snippet of the pseudo code. 
My question is- Does the below code not defeat the very notion of parallel asynchronous processing? 

The reason I ask this is because in the below code the main thread would submit a task to be executed in a different thread. After submitting the task in the queue, it blocks on Future.get() method for the task to return the value. I would rather have the task executed in the main thread rather than submitting to a different thread and waiting for the results. What is that I gained by executing the task in a new thread? 

I am aware that you could wait for a limited time etc, but then what if I really care about the result? The problem gets worse if there are multiple tasks to be executed. It seems to me that we are just doing the work synchronously. I am aware of the Guava library which provides a non blocking listener interface. But I am interested to know if my understanding is correct for the Future.get() API. If it is correct, why is the Future.get() designed to block thereby defeating the whole process of parallel processing?

Note - For the record, I use JAVA 6


    public static void main(String[] args){
    
    private ExectorService executorService = ...
    
    Future future = executorService.submit(new Callable(){
        public Object call() throws Exception {
            System.out.println(&quot;Asynchronous Callable&quot;);
            return &quot;Callable Result&quot;;
        }
    });
    
    System.out.println(&quot;future.get() = &quot; + future.get());
    }

Method call to Future.get() blocks. Is that really desirable?

I just finished reading this post: https://stackoverflow.com/questions/9276807/whats-the-advantage-of-a-java-5-threadpoolexecutor-over-a-java-7-forkjoinpool and felt that the answer is not straight enough.

Can you explain in simple language and examples, what are the **trade-offs** between Java 7&#39;s Fork-Join framework and the older solutions?

I also read the Google&#39;s #1 hit on the topic [Java Tip: When to use ForkJoinPool vs ExecutorService][1] from [javaworld.com][2] but the article doesn&#39;t answer the title question **when**, it talks about api differences mostly ...


  [1]: http://www.javaworld.com/article/2078440/enterprise-java/java-tip-when-to-use-forkjoinpool-vs-executorservice.html

  [2]: https://www.javaworld.com/

Java&#39;s Fork/Join vs ExecutorService - when to use which?

I am trying to execute lots of tasks using a ThreadPoolExecutor. Below is a hypothetical example:

    def workQueue = new ArrayBlockingQueue&lt;Runnable&gt;(3, false)
    def threadPoolExecutor = new ThreadPoolExecutor(3, 3, 1L, TimeUnit.HOURS, workQueue)
    for(int i = 0; i &lt; 100000; i++)
        threadPoolExecutor.execute(runnable)

The problem is that I quickly get a `java.util.concurrent.RejectedExecutionException` since the number of tasks exceeds the size of the work queue. However, the desired behavior I am looking for is to have the main thread block until there is room in the queue. What is the best way to accomplish this?


ThreadPoolExecutor Block When Queue Is Full?

When using an `ExecutorService` and `Future` objects (when submitting `Runnable` tasks), if I specify a timeout value to the future&#39;s get function, does the underlying thread get killed when a `TimeoutException` is thrown? 

Does a Future timeout kill the Thread execution

What is the difference between

    ExecutorService eService = Executors.newFixedThreadPool(2);
    eService.execute(new TestThread6());
    eService.execute(new TestThread6());
    eService.execute(new TestThread6());
    eService.awaitTermination(1, TimeUnit.NANOSECONDS);
    eService.shutdown();

and

    eService.shutdown();
    eService.awaitTermination(1, TimeUnit.NANOSECONDS);


I don&#39;t really understand `shutdown()`. This method does not wait for previously submitted tasks to complete execution. Does it mean `shutdown()` may terminate the tasks which have been submitted, but not completed? I tried some examples, they do not prove it, please give me an example. 


shutdown and awaitTermination which first call have any difference?

I am working on a multithreaded project in which I need to spawn multiple threads to measure the end to end performance of my client code, as I&#39;m doing Load and Performance testing. So I created the below code which is using `ExecutorService`.

Below is the code with `ExecutorService`:

    public class MultithreadingExample {
    
    	public static void main(String[] args) throws InterruptedException {
    
    		ExecutorService executor = Executors.newFixedThreadPool(20);
    		for (int i = 0; i &lt; 100; i++) {
    			executor.submit(new NewTask());
    		}
    
    		executor.shutdown();
    		executor.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS);
    	}
    }
    
    class NewTask implements Runnable {
    
    	@Override
    	public void run() {
    		//Measure the end to end latency of my client code
    	}	
    }

**Problem statement:**

Now I was reading some article on the Internet. I found out there is `ThreadPoolExecutor` as well. So I got confused which one I should be using.

If I replace my above code from:

    ExecutorService executor = Executors.newFixedThreadPool(20);
    	for (int i = 0; i &lt; 100; i++) {
    		executor.submit(new NewTask());
    	}

to:

    BlockingQueue&lt;Runnable&gt; threadPool = new LinkedBlockingQueue&lt;Runnable&gt;();
        
    ThreadPoolExecutor tpExecutor = new ThreadPoolExecutor(20, 2000, 0L, TimeUnit.MILLISECONDS, threadPool);
    
    tpExecutor.prestartAllCoreThreads();
        		
    	for (int i = 0; i &lt; 100; i++) {
    		tpExecutor.execute(new NewTask());
    	}

will this make any difference? I am trying to understand what is the difference between my original code using `ExecutorService` and the new code pasted using `ThreadPoolExecutor`. Some of my team mates said second one (ThreadPoolExecutor) is the right way to use.

Can anyone clarify this for me?

All Executorservice Solutions on Gang of Coders

Total of 26 Executorservice Solutions