It does not. Why would it? Unless you tell it to. There is a very valid concern here in case of a Callable for example. If you waited for the result for say 20 seconds and you did not get it, then you are not interested in the result anymore. At that time you should … Read more
You should call shutdown first. Otherwise, you might be waiting for a very long time, since awaitTermination doesn’t actually shut down your executor. If you wanted to wait for tasks to complete, rather than wait for the executor to shut down, then you should use invokeAll.
In some very narrow circumstances, you can implement a java.util.concurrent.RejectedExecutionHandler that does what you need. RejectedExecutionHandler block = new RejectedExecutionHandler() { rejectedExecution(Runnable r, ThreadPoolExecutor executor) { executor.getQueue().put( r ); } }; ThreadPoolExecutor pool = new … pool.setRejectedExecutionHandler(block); Now. This is a very bad idea for the following reasons It’s prone to deadlock because all the … Read more
Future offers you method isDone() which is not blocking and returns true if computation has completed, false otherwise. Future.get() is used to retrieve the result of computation. You have a couple of options: call isDone() and if the result is ready ask for it by invoking get(), notice how there is no blocking block indefinitely … Read more
Fork-join allows you to easily execute divide and conquer jobs, which have to be implemented manually if you want to execute it in ExecutorService. In practice ExecutorService is usually used to process many independent requests (aka transaction) concurrently, and fork-join when you want to accelerate one coherent job.
(Contrary to other answers) the thread-safety contract is documented: look in the interface javadocs (as opposed to javadoc of methods). For example, at the bottom of the ExecutorService javadoc you find: Memory consistency effects: Actions in a thread prior to the submission of a Runnable or Callable task to an ExecutorService happen-before any actions taken … Read more
Probably simplest and preferred solution is in Marco13’s answer so don’t get fooled by vote difference (this answer is few years older) or acceptance mark (it just means that this solution was appropriate for OP circumstances, not that it is best in general). You can use ThreadFactory to set threads inside Executor to daemons. This … Read more
I have done this same thing. The trick is to create a BlockingQueue where the offer() method is really a put(). (you can use whatever base BlockingQueue impl you want). public class LimitedQueue<E> extends LinkedBlockingQueue<E> { public LimitedQueue(int maxSize) { super(maxSize); } @Override public boolean offer(E e) { // turn offer() and add() into a … Read more
As you see from the JavaDoc execute(Runnable) does not return anything. However, submit(Callable<T>) returns a Future object which allows a way for you to programatically cancel the running thread later as well as get the T that is returned when the Callable completes. See JavaDoc of Future for more details Future<?> future = executor.submit(longRunningJob); … … Read more
The shutdown() method does one thing: prevents clients to send more work to the executor service. This means all the existing tasks will still run to completion unless other actions are taken. This is true even for scheduled tasks, e.g., for a ScheduledExecutorService: new instances of the scheduled task won’t run. It also frees up … Read more