Menu
So far in my experiments with the executorservice I've had a lot of advice that involves using future.get, and then future.cancel in order to throw a thread interrupt which then needs to be caught in the thread, and handled there. My question is a little different.
Assuming that I was running a thread that simply kept track of how long things were running and if they passed by some threshold, would this be a good way to kill the executorservice and all running threads?
Example thought process:
ExecutorService threadPool = Executors.newFixedThreadPool(12);
timekeeper.start();
List<Future<?>> taskList = new ArrayList<Future<?>>();
for (int i = 0; i < objectArray.length; i++) {
Future<?> task = threadPool.submit(new ThreadHandler(objectArray[i], i));
taskList.add(task);
Thread.sleep(500);
}
if(timekeeper.now() > 60)
threadpool.shutdownNow();
}
Would this work? I have no way to check since my threads fail extremely infrequently (about 1/700 runs, and only at certain hours of the day when I'm not working).
971
Whenever we want to stop a thread from running state by calling stop() method of Thread class in Java. This method stops the execution of a running thread and removes it from the waiting threads pool and garbage collected. A thread will also move to the dead state automatically when it reaches the end of its method.
To properly shut down an ExecutorService, we have the shutdown() and shutdownNow() APIs. The shutdown() method doesn't cause immediate destruction of the ExecutorService. It will make the ExecutorService stop accepting new tasks and shut down after all running threads finish their current work: executorService.
An unused ExecutorService should be shut down to allow reclamation of its resources.
Using shutdown() and awaitTermination() In general, the ExecutorService will not be automatically destroyed when there is no task to process. It will stay alive and wait for new tasks to come.
The shutdownNow method attempts to interrupt all of active task threads, and this would only work if the tasks were coded to respected interrupts. They would need to:
check to see if the interrupt flag has been set in long running loops, and
deal with InterruptedExceptions correctly.
Basically the tasks needs to cooperate for interrupts to work. If they don't cooperate, there is no safe and reliable way to stop them ... apart from exiting the JVM.
Above someone mentioned the .stop() method as a comment, can you provide commentary as to why this would be a bad idea?
The Thread.stop() method is deprecated because it is fundamentally unsafe. Stopping a thread can leave critical data structures in an intermediate state, and can interfere with other threads that were interacting with it in various ways. It is theoretically possible to use stop safely, but it is difficult to work out a set of general preconditions that are sufficient to ensure that nothing bad happens.
148
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
