CODEWITHSUNDEEP
javaexecutorserviceexecutor
Frank
Frank

Reputation: 31086

How is an executor terminated in my Java program?

This question is related to my previous question : Why the speed of a Java process inside multiple loops slows down as it goes?

In order to find the problem of that question, I looked closely at my code and found some executors in my app are not terminated, since I'm in the process of learning how to use executors, I copied some online sample codes and used them in my app, and I'm not sure if I'm using them correctly.

What's the difference between the following 2 approaches of using executors ?

[1]

 Executor executor=Executors.newFixedThreadPool(30);
 CountDownLatch doneSignal=new CountDownLatch(280);

 for (int N=0;N<280;N++)
 {
   ...
   executor.execute(new SampleCountRunner(doneSignal,...));
 }
 try { doneSignal.await(); }
 catch (Exception e) { e.printStackTrace(); }

[2]

ExecutorService executor=Executors.newFixedThreadPool(30);

for (int i=0;i<60;i++)
{
  ...
  executor.execute(new xyzRunner(...));
}
executor.shutdown();

while (!executor.isTerminated()) { }

It seems to me after the 1st one is done, the executor still has an active pool of threads running and waiting for more tasks, they DO consume cpu time and memory.

The 2nd one will terminate all active threads in the pool after the shutdown() method is run, and all previously active threads won't take any more cpu time or memory after that point.

So my questions are :

[1] Am I correct ?

[2] How to terminate the pool of threads in the 1st case ? There is no "executor.shutdown()" for Executor

Edit :

Problem solved, I changed Executor in [1] to ExecutorService, and added :

   executor.shutdown();
   while (!executor.isTerminated()) { }

Now when my program ends, it won't have a lot of threads active any more.

Upvotes: 1

Views: 4479

Answers (2)

Brett Okken
Brett Okken

Reputation: 6306

Thread pools (ExecutorService) should generally speaking not be created/destroyed regularly. Rather they should be long lived (perhaps entire life of application) to avoid the (significant) overhead of thread creation/destruction.

If you want to submit a list of tasks and wait for all to complete, use ExecutorService.invokeAll() rather than trying to track completion by a countdown latch.

The ExecutorService interface provides 2 mechanisms to shutdown: shutdown and shutdownNow. The first simply stops taking new jobs and will stop threads as currently executing and already submitted work is done. The second will attempt to interrupt all work in progress and will not even work on already submitted but not yet started jobs.

Upvotes: 1

Bhaskar
Bhaskar

Reputation: 7523

It seems to me after the 1st one is done, the executor still has an active pool of threads running and waiting for more tasks, they DO consume cpu time and memory.

Not exactly. In first approach , after the tasks are all done ( as signalled by the latch ) , the executor is definitely NOT shutdown - but the threads in the executor do NOT consume cpu ( they consume minimum memory needed for thier structures yes ).

In this approach - you are explicitly in control of knowing when and how your tasks are completed. You can know if the tasks have succeeded or failed , and can decide to resubmit the tasks if needed.

The 2nd one will terminate all active threads in the pool after the shutdown() method is run, and all previously active threads won't take any more cpu time or memory after that point.

Again ,not exactly .In this approach , the ExecutorService does not shutdown immediately after the call to shutdown(). It waits for the already submitted tasks to complete , but here you do not directly know if these tasks completed successfully or they failed ( by throwing some Exception ).

And until the already submitted tasks are completed - your isShutDown() will do a tight loop ( it will spike the cpu to near 100% ) .

Upvotes: 3

Related Questions