CODEWITHSUNDEEP
javamultithreadingexecutorservice
userx
userx

Reputation: 3773

Executor corepoolsize as zero with a finite LinkedBlockingQueue

I was going through Java Concurrency in Practice and came across a statement under the section 8.3.1 Thread Creation And Teardown. Here is the statement - "the implementation attempts to maintain the pool at this size even when there are no tasks to execute and will not create more threads than this unless the work queue is full." To verify the same, I wrote a small code 

package com.executor;

import java.util.concurrent.BlockingQueue;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.RejectedExecutionException;
import java.util.concurrent.SynchronousQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;


public class MyJobSubmitterThread extends Thread {

    public static ExecutorService objExecutorService = new ThreadPoolExecutor(0, 1, 10, TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>(2));

    public static int counter = 1;
    @Override
    public void run() {
        //Using Runnable
        while(!objExecutorService.isShutdown()){
            try{
            objExecutorService.execute(new RandomNumberGenerator());
            if(counter > 10){
                objExecutorService.shutdownNow();
                if(objExecutorService.isTerminated()){
                    System.out.println("Runnable - Terminated");
                }
                //objExecutorService.execute(new RandomNumberGenerator());
            }
            int objBlockingQueueSize = ((ThreadPoolExecutor)objExecutorService).getQueue().size();
            ++counter;
            }catch (RejectedExecutionException e) {
                // TODO: handle exception
                e.printStackTrace();
            }
        }

    }
}

Deliberately not putting the code of RandomNumberGenerator class as is not required in context of this question.

As per the statement quoted above, a Thread should not have got created and started unless the a third task is submitted to the queue, but contrary to it, the Thread got created and started.When the thread died after 10 sec of keep alive time, it again got created when a job was just submitted. When I looked at the execute method code in Java 1.7 source, it is like 

else if (workerCountOf(recheck) == 0)
            addWorker(null, false);

Could someone please explain why the behavior of the code is different from what is stated in JCIP book or vice-versa ? Am I missing a point here ?

Upvotes: 2

Views: 1436

Answers (2)

Serdar
Serdar

Reputation: 383

You set core pool size to 0 and max pool size to 1. This means it has at most one thread to execute the tasks. And since thread count is bigger than core pool size (1>0) this thread will be removed after it stays idle for the keep alive time. So the situation is normal I think.

ThreadPoolExecutor tries to keep the thread count equal to the core pool size, by removing idle threads if thread count is bigger than core pool size and creating new thread every time until it reaches core pool size.

Upvotes: 0

jtahlborn
jtahlborn

Reputation: 53694

The statement from the book is accurate with the caveat that the ThreadPoolExecutor ensures at least 1 thread is running when there is work to do (i.e. corePoolSize == 0 is a special case).

Upvotes: 2

Related Questions