What Happens When corePoolSize=0? Deep Dive into ThreadPoolExecutor Behavior

The "Java Development Manual" stresses that thread resources must be provided via a thread pool, specifically using ThreadPoolExecutor . A thread pool avoids excessive thread switching and out‑of‑memory errors, but misconfiguration can re‑introduce these problems.

1. What Happens When corePoolSize=0?

When corePoolSize is set to 0, the executor first checks the waiting queue capacity; if there is space, tasks are queued without creating new threads. This behavior changed after JDK 1.6. The current execute implementation adds a task to the queue and, if the pool is empty, creates a worker thread to consume the queued task:

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);

Thus, with corePoolSize=0, tasks are queued first; only when the queue is full does the pool create new threads.

2. Are Core Threads Created Immediately?

Core threads are not started at pool creation. They start only when a task is submitted, unless prestartCoreThread or prestartAllCoreThreads is called to pre‑start them.

prestartCoreThread : Starts a single core thread, which then idly waits for work.

prestartAllCoreThreads : Starts all core threads.

3. Do Core Threads Ever Terminate?

Before JDK 1.6, core threads were kept alive indefinitely. Since JDK 1.6, allowsCoreThreadTimeOut can be set to true to allow idle core threads to terminate, making the effect of corePoolSize=0 similar to allowsCoreThreadTimeOut=true && corePoolSize=1, though the implementation differs.

4. How to Keep Threads from Being Destroyed?

The pool uses an internal Worker class that runs a loop calling getTask(). If the pool is empty, workQueue.take() blocks the worker until a new task arrives. Non‑core threads use workQueue.poll(keepAliveTime, …) and terminate after the timeout.

5. Problems with Too Many Idle Threads

Idle threads consume memory (stack, local variables, ThreadLocal data). Large numbers of idle threads can increase JVM heap pressure, trigger Young GC due to TLAB allocation, and retain ThreadLocal caches.

6. Effect of keepAliveTime=0

In JDK 1.8, keepAliveTime=0 means non‑core threads terminate immediately after completing a task. For core threads to time out, allowsCoreThreadTimeOut must be enabled and keepAliveTime must be greater than 0.

7. Exception Handling in Thread Pools

Both execute and submit can wrap task code with try‑catch. submit returns a Future whose get() re‑throws any exception captured by the underlying FutureTask:

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

The FutureTask.run() method catches Throwable and stores it in an outcome field, which Future.get() later reports.

8. Should a Thread Pool Be Shut Down?

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

9. shutdown vs shutdownNow

shutdown : Graceful shutdown; waits for queued tasks to finish.

shutdownNow : Immediate shutdown; attempts to stop running tasks and returns pending tasks.

10. Spring Utilities Similar to ThreadPoolExecutor

SimpleAsyncTaskExecutor – creates a new thread per task (no pooling).

SyncTaskExecutor – executes tasks synchronously in the calling thread.

ConcurrentTaskExecutor – adapts an existing Executor, not recommended.

SimpleThreadPoolTaskExecutor – integrates with Quartz lifecycle.

Best‑Practice Summary

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

Give threads meaningful names via a custom ThreadFactory.

Use separate pools for different business domains.

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

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

Enable allowsCoreThreadTimeOut in resource‑constrained environments.

Handle exceptions in task code with try‑catch for fine‑grained control.

Monitor pool metrics via ThreadPoolExecutor APIs for tuning.

ThreadPoolExecutor Initialization Example

private static final ThreadPoolExecutor pool;
static {
    ThreadFactory threadFactory = new ThreadFactoryBuilder()
        .setNameFormat("po-detail-pool-%d")
        .build();
    pool = new ThreadPoolExecutor(
        4, 8, 60L, TimeUnit.MILLISECONDS,
        new LinkedBlockingQueue<>(512),
        threadFactory, new ThreadPoolExecutor.AbortPolicy());
    pool.allowCoreThreadTimeOut(true);
}

Key parameters: corePoolSize = 4 for quick startup, maximumPoolSize = 8 for I/O‑intensive workloads, keepAliveTime = 60 ms to release idle threads, and a bounded queue of 512 tasks.