Why ThreadPoolExecutor Won’t Expand When the Queue Isn’t Full

ThreadPoolExecutor Execution Priority

When maximumPoolSize is set to 100, the pool does not immediately create 100 threads. The executor first tries to fill core threads, then enqueues the task, and only creates non‑core threads after the queue is full.

Common Misconception

Many developers equate “maximum pool size” with the current active thread count and increase maximumPoolSize to relieve backlog. In practice, the queue capacity usually determines system behavior before the maximum thread count is reached.

What a Thread Pool Actually Solves

The typical configuration uses core threads for steady load, a queue to absorb short spikes, and a maximum thread count to prevent the queue from growing without bound. This works for workloads with relatively stable execution time, acceptable queuing, and downstream resources that need protection (e.g., batch notifications, asynchronous logging, background data processing).

A thread pool does not provide business‑level guarantees such as mutual exclusion, idempotence, state‑machine handling, fault recovery, or data consistency. Examples of problems that remain unsolved by the pool:

Concurrent inventory deduction requires mutex and transaction boundaries.

Duplicate message delivery is an idempotence issue.

Order state transitions are a state‑machine problem.

Process crashes during task execution need fault‑recovery mechanisms.

Inconsistent database and message results are consistency problems.

Three if Statements That Determine Expansion Order

The core path of ThreadPoolExecutor.execute() in the JDK can be expressed as:

int c = ctl.get(); // read pool state and worker count
if (workerCountOf(c) < corePoolSize) { // core threads not full, try to create
    if (addWorker(command, true))
        return; // created core thread, task handed off
    c = ctl.get(); // retry on failure or state change
}
if (isRunning(c) && workQueue.offer(command)) { // core full, try to enqueue
    int recheck = ctl.get(); // re‑check after enqueue
    if (!isRunning(recheck) && remove(command))
        reject(command); // queue not empty but pool shutting down
    else if (workerCountOf(recheck) == 0)
        addWorker(null, false); // no workers, create one to consume queue
} else if (!addWorker(command, false)) {
    reject(command); // enqueue failed, try to create non‑core thread, else reject
}

Line 6 ( workQueue.offer(command)) succeeds for most queue implementations; when it succeeds, the logic that creates a non‑core thread (line 12) is skipped.

If a large queue is configured while expecting maximumPoolSize to trigger automatic expansion, the semantics conflict: a large queue means “wait”, whereas expansion means “cannot wait”.

Line 3 is not an absolute guarantee. Multiple submitting threads may race, and the pool may be shut down during the attempt, so the source re‑reads ctl instead of relying on stale state.

Queue Types Define Expansion Timing

Example configuration:

corePoolSize = 2
maximumPoolSize = 5
queue capacity = 10

When tasks are submitted continuously:

Tasks 1‑2 create core threads.

Tasks 3‑12 are placed in the queue.

Task 13 finds the queue full; the pool attempts to create a third thread.

The pool can grow up to five threads. Subsequent submissions that cannot create additional threads invoke the rejection handler.

Conceptual Meanings

corePoolSize

: Number of threads the pool tries to keep alive. maximumPoolSize: Upper limit of threads when the queue cannot accept more tasks.

Active thread count: Current number of threads actually executing tasks.

Queue Implementations and Their Expansion Behaviour

Unbounded queue – offer almost always succeeds; non‑core threads are rarely created. Suitable when task volume is controllable and queuing risk is acceptable.

Bounded queue – Expansion to maximumPoolSize occurs only after the queue is full. Provides a clear boundary between queuing, expansion, and rejection.

SynchronousQueue – Does not store tasks; a failed hand‑off immediately triggers thread creation. Appropriate for short‑lived, high‑real‑time tasks that must be handed off quickly, but not for uncontrolled traffic bursts.

With an unbounded queue, maximumPoolSize is effectively inert; the risk shifts from “too many threads” to “task backlog”, which can cause rising latency and memory pressure.

With a SynchronousQueue, submissions that exceed thread supply cause rapid expansion or rejection, making it unsuitable for scenarios with uncontrolled spikes.

Rejection Policies as Part of Capacity Boundaries

When the queue is full and a new thread cannot be created (because the maximum has been reached or the pool is shut down), the RejectedExecutionHandler is invoked. Common handlers: CallerRunsPolicy – The submitting thread executes the task, providing back‑pressure but potentially slowing request threads. AbortPolicy – Throws an exception, suitable when failures must be handled explicitly.

Discard policies – Only appropriate for tasks that can be safely dropped; they must not be used for orders, inventory deductions, or state changes.

Invocation of a rejection handler indicates that the system has explicitly run out of capacity, not that the thread pool is broken.