Understanding How ThreadPoolExecutor Recycles Worker Threads in JDK 1.8

After reading the source code of JDK's ThreadPoolExecutor , the author gained a general view of task execution flow and now explores how the pool recycles idle worker threads, using JDK 1.8 as the reference.

1. runWorker(Worker w)

When a worker thread starts, it enters runWorker(Worker w) , which contains a while loop that repeatedly fetches tasks. If a task is obtained it is executed; if no task is available or an exception occurs, the loop exits and processWorkerExit(w, completedAbruptly) removes the worker.

The first task comes from firstTask (executed only once); subsequent tasks are obtained via getTask() . When getTask() returns null , the thread terminates.

2. When getTask() Returns null

Two situations cause getTask() to return null (highlighted in the red boxes of the diagram):

The pool state is STOP , TIDYING , TERMINATED , or SHUTDOWN with an empty work queue.

The current worker count exceeds the maximum pool size or a worker has timed out, and the work queue is empty.

3. Scenario‑Based Analysis of Thread Recycling

3.1 No shutdown() – RUNNING state after all tasks finish

In this case the pool reduces the number of workers to the core pool size. For example, with corePoolSize=4 and maximumPoolSize=8 , the pool may grow to eight threads while the queue is full, then shrink back to four when tasks are scarce (assuming allowCoreThreadTimeOut=false ).

Since the pool remains in RUNNING , the first condition never triggers. When a worker cannot obtain a task, it checks the second condition: if the queue is empty, a CAS operation decrements the worker count; if the CAS fails, the loop repeats.

The CAS ensures that multiple workers attempting to shrink simultaneously do not reduce the count below the core size.

3.2 shutdown() called – all tasks completed

After shutdown() , an interrupt signal is sent to every idle worker.

The interrupt handling is performed in processWorkerExit after the worker has been removed from the workers set and tryTerminate() is invoked.

3.2.1 All tasks finished, workers blocked

The interrupt wakes the blocked thread, the loop reaches condition 1, the worker count is decremented, and the thread exits.

3.2.2 Tasks still running

When shutdown() occurs before all tasks finish, workers may still be executing. If a worker is blocked in getTask() , the interrupt causes BlockingQueue methods to throw InterruptedException , which is caught and the loop continues if the queue is not empty.

Both LinkedBlockingQueue and ArrayBlockingQueue use lockInterruptibly() , which resets the thread's interrupt status after handling, allowing the worker to retry without further exceptions.

When only a subset of workers obtain remaining tasks, the others block. Because at least one task is still in the queue, some workers will succeed, finish, and then encounter condition 1, returning null and being reclaimed.

The processWorkerExit method also calls tryTerminate() , which may interrupt an arbitrary idle worker to ensure all blocked threads are eventually awakened and terminated.

4. Summary

ThreadPoolExecutor recycles a worker thread whenever getTask() returns null . Two main scenarios exist:

1) No shutdown(), RUNNING state after all tasks finish

If the current worker count exceeds corePoolSize , timed‑out workers are CAS‑decremented and terminated; once the count reaches the core size, workers may block indefinitely.

2) shutdown() called, all tasks finish

Shutdown sends an interrupt to every worker. Blocked workers are awakened, encounter condition 1, and exit; workers still executing tasks continue until completion, after which they are reclaimed via processWorkerExit and tryTerminate() .

The analysis took roughly four hours of writing plus one hour of thinking, and while the author is not certain of every detail, the exercise deepened his understanding of Java thread‑pool internals.