I used to work on an app with long running threads. We do this at shutdown, BlockingQueue<Runnable> queue = threadPool.getQueue(); List<Runnable> list = new ArrayList<Runnable>(); int tasks = queue.drainTo(list); The list is saved to a file. On startup, the list is added back to the pool so we don’t lose any jobs.
In this case, there is no way to cancel the Future once it has actually started running, because you’re relying on the behavior of concurrent.futures.Future, and its docs state the following: cancel() Attempt to cancel the call. If the call is currently being executed and cannot be cancelled then the method will return False, otherwise … Read more
The Javadoc of both scheduleAtFixedRate and scheduleWithFixedDelay says “If any execution of the task encounters an exception, subsequent executions are suppressed.” I don’t find that to be exactly crystal clear, but it seems to be saying that if your run method throws any kind of exception, then the scheduler will effectively drop that task. Any … Read more
I faced a similar situation in my previous project, and after my code blew in the face of an angry customer, my buddies and I added two big safe-guards: In the infinite loop, catch Errors too, not just exceptions. Sometimes unexcepted things happen and Java throws an Error at you, not an Exception. Use a … Read more
The clean workaround is to use ExecutorService.submit() instead of execute(). This returns you a Future which you can use to retrieve the result or exception of the task: ExecutorService executor = Executors.newSingleThreadExecutor(); Runnable task = new Runnable() { public void run() { throw new RuntimeException(“foo”); } }; Future<?> future = executor.submit(task); try { future.get(); } … Read more
There is a more direct way: ThreadPoolExecutor executor = new ThreadPoolExecutor( 1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>() ); // add jobs // … int size = executor.getQueue().size(); This is directly copied from Executors.newSingleThreadExecutor in JDK 1.6. The LinkedBlockingQueue that is passed to the constructor is actually the very object that you will get back from … Read more
Work stealing is a technique used by modern thread-pools in order to decrease contention on the work queue. A classical threadpool has one queue, and each thread-pool-thread locks the queue, dequeue a task and then unlocks the queue. If the tasks are short and there are many of them, there is a lot of contention … Read more
Currently the only concrete implementations of the Executor interface are the ThreadPoolExecutor and the ScheduledThreadpoolExecutor Instead of using the utility / factory class Executors, you should create an instance using a constructor. You can pass a BlockingQueue to the constructors of the ThreadPoolExecutor. One of the implementations of the BlockingQueue, the PriorityBlockingQueue lets you pass … Read more
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.
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