23

I have a scenario where I have to execute 5 thread asynchronously for the same callable. As far as I understand, there are two options:

1) using submit(Callable)

ExecutorService executorService = Executors.newFixedThreadPool(5);
List<Future<String>> futures = new ArrayList<>();
for(Callable callableItem: myCallableList){
    futures.add(executorService.submit(callableItem));
}

2) using invokeAll(Collections of Callable)

ExecutorService executorService = Executors.newFixedThreadPool(5);
List<Future<String>> futures = executorService.invokeAll(myCallableList));
  1. What should be the preferred way?
  2. Is there any disadvantage or performance impact in any of them compared to the other one?
Ankit
  • 2,943
  • 6
  • 32
  • 58

3 Answers3

24

Option 1 : You are submitting the tasks to ExecutorService and you are not waiting for the completion of all tasks, which have been submitted to ExecutorService

Option 2 : You are waiting for completion of all tasks, which have been submitted to ExecutorService.

What should be the preferred way?

Depending on application requirement, either of them is preferred.

  1. If you don't want to wait after task submit() to ExecutorService, prefer Option 1.
  2. If you need to wait for completion of all tasks, which have been submitted to ExecutorService, prefer Option 2.

Is there any disadvantage or performance impact in any of them compared to the other one?

If your application demands Option 2, you have to wait for completion of all tasks submitted to ExecutorService unlike in Option 1. Performance is not criteria for comparison as both are designed for two different purposes.

And one more important thing: Whatever option you prefer, FutureTask swallows Exceptions during task execution. You have to be careful. Have a look at this SE question: Handling Exceptions for ThreadPoolExecutor

With Java 8, you have one more option: ExecutorCompletionService

A CompletionService that uses a supplied Executor to execute tasks. This class arranges that submitted tasks are, upon completion, placed on a queue accessible using take. The class is lightweight enough to be suitable for transient use when processing groups of tasks.

Have a look at related SE question: ExecutorCompletionService? Why do need one if we have invokeAll?

Jason Law
  • 918
  • 1
  • 9
  • 20
Ravindra babu
  • 45,953
  • 8
  • 231
  • 206
  • @downvoter, read question and anwser again to validate your judgement. – Ravindra babu Jan 15 '18 at 17:34
  • You said following for option 2: "You are waiting for completion of all tasks". What do you mean by "waiting"? Because the [doc](https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ExecutorService.html#invokeAll(java.util.Collection)) does not say anything about "waiting". Do you mean to say that if we `submit()` any more tasks to same `ExecutorService` after calling `invokeAll()`, those tasks will be delayed till the currently invoked list of tasks execute completely? – Maha Apr 06 '20 at 11:24
  • Read the documentation of invokeAll:https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ExecutorService.html => Executes the given tasks, returning a list of Futures holding their status and results when all complete – Ravindra babu Apr 06 '20 at 17:35
  • Does "when all complete" mean the call to `invokeAll()` is blocking till all argument `Callable`s complete their execution? – Maha Apr 06 '20 at 18:41
  • Next statement after invokeAll() executes after all tasks complete their execution – Ravindra babu Apr 07 '20 at 08:40
5

EDIT:

There is actually a difference between them. For some reason, invokeAll() will call get() for each future produced. Thus, it will wait the tasks to finish and that is why it may throw InterruptedException (while submit() throws nothing).

That's the Javadoc for the invokeAll() method:

Executes the given tasks, returning a list of Futures holding their status and results when all complete.

So, both strategies basically do the same, but if you call invokeAll() you'll be blocked until all tasks are done.


Original (incomplete) answer:

The invokeAll() method is there exactly for situations like these. You should definitely use it.

You don't really need to instantiate that List, though:

ExecutorService executorService = Executors.newFixedThreadPool(5);
List<Future<String>> futures = executorService.invokeAll(myCallableList));

This should be enough, and it looks way cleaner than the first alternative.

Fred Porciúncula
  • 7,984
  • 3
  • 38
  • 54
  • If invokeAll will block until all tasks are done, then isin't submit better. I can do processing of other tasks after submitting required tasks to ExecutorService – Ankit Dec 24 '15 at 04:32
  • Yeah, if you do have other tasks to do in your main thread while your other threads are working, then using submit is better. – Fred Porciúncula Dec 24 '15 at 09:26
1

Suppose you have a task whose result depends on number of independentaly executable tasks. But for initial task to complete you only have limited time. Like its an API call.

So for example you have 100ms for top level task to complete and there are 10 dependant tasks as well. For that if you are using a submit here how the code will look like.

List<Callable> tasks = []// assume contains sub tasks
List<Future> futures = [] 
for(Callable task: tasks) {
   futures.add(service.submit(task));
}

for(Future futute: futures) {
    future.get(100, TimeUnit.MILLISECONDS);
}

So if each of sub tasks took exaclty 50ms to complete the above piece of code would take 50 ms. But if each of sub tasks took 1000 ms to complete the above would take 100 * 10 = 1000 ms or 1s. This is making difficult to compute the total time to be less than 100ms for all subtasks.

invokeAll method helps us in such scenario

List<Futures> futures = service.invokeall(tasks, 100, TimeUnit.MILLISECONDS)
for(Future future: futures) {
   if(!future.isCancelled()) {
       results.add(future.get());
   }
}

This way the maximum time it would take is inly 100 ms even if individual of subtasks took more than that.

  • if sub tasks took 99ms, 199ms, 299ms... `future.get(100, TimeUnit.MILLISECONDS);` still work, it's not we want. – GeekLei Aug 24 '18 at 02:59