Why corePoolSize=0 Behaves Differently in Java ThreadPoolExecutor and How to Optimize It

The Java "Java Development Manual" stresses that thread resources must be provided via a thread pool, typically using ThreadPoolExecutor. Proper pool configuration avoids excessive context switching and out‑of‑memory errors, but misconfiguration can reintroduce these problems.

1. What Happens When corePoolSize=0?

Older JDK versions (≤1.6) would check the waiting queue first; if there was capacity, tasks were queued and no new thread was created. Since JDK 1.6 the implementation changed. The key part of execute is:

int c = ctl.get();
if (workerCountOf(c) < corePoolSize) {
    if (addWorker(command, true))
        return;
    c = ctl.get();
}
if (isRunning(c) && workQueue.offer(command)) {
    int recheck = ctl.get();
    if (!isRunning(recheck) && remove(command))
        reject(command);
    else if (workerCountOf(recheck) == 0)
        addWorker(null, false);
} else if (!addWorker(command, false))
    reject(command);

With corePoolSize=0, the pool first tries to queue the task; only when the queue is full does it create a new thread.

2. Are Core Threads Created Immediately?

No. A newly created ThreadPoolExecutor does not start core threads until a task is submitted, unless prestartCoreThread() or prestartAllCoreThreads() is invoked to start them proactively.

3. Do Core Threads Ever Terminate?

Before JDK 1.6 core threads were kept alive indefinitely. Since JDK 1.6 you can call allowsCoreThreadTimeOut(true); when this flag is true, idle core threads may be terminated, making the effect of corePoolSize=0 similar to allowsCoreThreadTimeOut=true && corePoolSize=1, though the internal details differ.

4. How to Keep Threads from Being Destroyed

The pool uses an internal Worker class that runs a loop calling getTask(). As long as getTask() returns a non‑null Runnable, the worker stays alive.

final void runWorker(Worker w) {
    Thread wt = Thread.currentThread();
    Runnable task = w.firstTask;
    w.firstTask = null;
    w.unlock(); // allow interrupts
    boolean completedAbruptly = true;
    try {
        while (task != null || (task = getTask()) != null) {
            w.lock();
            // execute the task
            try {
                beforeExecute(wt, task);
                task.run();
            } finally {
                afterExecute(task, null);
            }
            task = null;
            w.completedTasks++;
            w.unlock();
        }
        completedAbruptly = false;
    } finally {
        processWorkerExit(w, completedAbruptly);
    }
}

getTask()

first tries workQueue.take() (blocking) for core threads, and workQueue.poll(keepAliveTime, …) for non‑core threads, allowing idle non‑core threads to time out.

5. Problems of Too Many Idle Threads

Idle threads still consume memory: JVM stack, ThreadLocal entries, local variable frames, and TLAB space. Large numbers of idle threads can trigger frequent Young GCs if the Eden space becomes insufficient.

6. Effect of keepAliveTime=0

In JDK 1.8, keepAliveTime=0 means non‑core threads terminate immediately after completing a task. The default keepAliveTime must be positive when allowsCoreThreadTimeOut is enabled; otherwise initialization fails.

7. Exception Handling in Thread Pools

Both execute() and submit() ultimately call execute. submit wraps the task in a FutureTask, allowing the caller to retrieve exceptions via Future.get(). Example of submit implementation:

public Future<?> submit(Runnable task) {
    if (task == null) throw new NullPointerException();
    RunnableFuture<Void> ftask = newTaskFor(task, null);
    execute(ftask);
    return ftask;
}

For custom handling you can override afterExecute(Runnable r, Throwable t) in a subclass of ThreadPoolExecutor or provide a Thread.UncaughtExceptionHandler via a custom ThreadFactory. Note that afterExecute does not receive exceptions from tasks submitted via submit because FutureTask catches them internally.

8. Should You Shut Down a ThreadPool?

Typically the pool’s lifecycle follows the service’s lifecycle. When a service stops, call shutdown(). If the service runs continuously, explicit shutdown is not required.

9. shutdown vs shutdownNow

shutdown : graceful shutdown; waits for already submitted tasks to finish.

shutdownNow : immediate shutdown; attempts to stop running tasks and returns tasks that were awaiting execution.

10. Spring Utilities Similar to ThreadPoolExecutor

SimpleAsyncTaskExecutor

: creates a new thread for each task (no pooling). SyncTaskExecutor: executes tasks synchronously in the calling thread. ConcurrentTaskExecutor: adapts an existing Executor, used only when ThreadPoolTaskExecutor is insufficient. SimpleThreadPoolTaskExecutor: integrates with Quartz and Spring lifecycle callbacks.

Best‑Practice Summary

Prefer constructing ThreadPoolExecutor directly instead of using Executors.newFixedThreadPool or newCachedThreadPool.

Give threads meaningful names via a custom ThreadFactory for easier debugging.

Separate business domains into distinct thread pools.

For CPU‑bound work, set pool size to CPU cores + 1; for I/O‑bound work, consider 2 × CPU cores.

Avoid unbounded work queues; use bounded queues to prevent OOM.

Enable allowsCoreThreadTimeOut(true) in resource‑constrained environments.

Handle task exceptions with explicit try‑catch inside the task or by overriding afterExecute / providing an UncaughtExceptionHandler.

Monitor pool metrics (active threads, queue size, rejected tasks) via ThreadPoolExecutor APIs for proactive tuning.