Internal Working of newFixedThreadPool

Question

Kindly help me in understanding the internal flow of newFixedThreadPool (or Cached)

When we write below statements, ExecutorService e=Executors.newFixedThreadPool(3)

Answer 1

FYI: Here is a very simple implementation of a thread pool.

class MyThreadPool implements java.util.concurrent.Executor 
{
    private final java.util.concurrent.BlockingQueue<Runnable> queue;

    public MyThreadPool(int numThreads) {
        queue = new java.util.concurrent.LinkedBlockingQueue<>();
        for (int i=0 ; i<numThreads ; i++) {
            new Thread(new Runnable(){
                @Override
                public void run() {
                    while(true) {
                        queue.take().run();
                    }
                }
            }).start();
        }
    }

    @Override
    public void execute(Runnable command) {
        queue.put(command);
    }
}

This won't compile because I didn't deal with InterruptedException, and in a real thread pool, you would also want to deal with exceptions that might be thrown by the given command, but it should give you a rough idea of what a thread pool does.

It creates a queue and an arbitrary number of worker threads. The worker threads compete with one another to consume commands from the queue. The queue is a BlockingQueue, so the workers all sleep whenever the queue is empty.

Other threads may produce new commands (i.e., Runnable objects), and call the execute(command) method to put the new commands in the queue. The commands will be performed (i.e., their run methods will be called) by the worker threads in approximately* the same order that they were enqueued.

---

• Approximately, because worker A could pick a new command from the queue, and then lose its time slice before calling the command's .run() method. Other workers could then pick other commands from the queue and perform them before the scheduler allows worker A to run again.

Answer 2

When you execute ExecutorService e=Executors.newFixedThreadPool(3); a thread pool will be created with 3 threads inside it. And these 3 threads will be used to execute any task executed on you e object.

When you try to execute tasks through ExecutorService then it will get added to a tasks queue, if number of threads in pool are greater than number of tasks, then as soon as some task will come, some free thread in the pool will be picked and used to execute task.

When number of tasks become greater than number of threads in pool, then they will be added in pipleline in the queue, and as soon as some thread as finished execution, that thread will be used to execute task from the queue pipeline.

Thread pooling:
The thread which has just finished will not terminate. Pleas note that it is a thread pool, so threads are pooled, which means that they will not terminate (typically, until you have some timeout or some other mechanism) but will go back in pool so that they can be reused. And that's the reason your 4 and 5th runnable will be executed through those pooled threads.

"no new thread will be created but work will be waiting for a thread to be free."

This is same as discussed above that then they put be waiting in the queue, and as soon as some thread is done with the task execution, waiting tasks from the queue will be pooled and be executed from the free thread, and this will happen until all the tasks from the queue is cleaned up.

No new thread will be created because you have used newFixedThreadPool, so a fixed thread pool of 3 threads is created and they only will be used to process all the tasks requested coming to that particular instance of ExecutorService and in your case it is e.

Other thread pooling options:
You can create a thread pool in several ways using java.util.concurrent.Executors. For example, using Executors#newCachedThreadPool() you can create a thread pool that creates new threads as needed, but will reuse previously constructed threads when they are available.
Check all available ways to find which best suits you.