ThreadPoolExecutor Tuning

## What a thread pool is Creating an operating-system thread is expensive (memory for its stack, kernel bookkeeping, scheduling). If a program created a brand-new thread for every small task it would waste resources and could run out of memory. A **thread pool** solves this by keeping a fixed-ish set of reusable **worker threads** alive and feeding them a stream of **tasks** (units of work, expressed as `Runnable` or `Callable`). When a task finishes, its thread stays alive and picks up the next task instead of dying. In Java the standard, fully configurable thread pool is **`java.util.concurrent.ThreadPoolExecutor`**. The convenience factory methods on `Executors` (e.g. `Executors.newFixedThreadPool`) are just thin wrappers that build a `ThreadPoolExecutor` with preset arguments. ## The six constructor parameters The most general constructor is: ``` ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler) ``` - **corePoolSize** — the number of worker threads the pool tries to keep alive even when they have nothing to do. New tasks normally cause a new core thread to be created until this many exist (see the submission logic question). By default core threads are *not* timed out; you can opt in with `allowCoreThreadTimeOut(true)`. - **maximumPoolSize** — the absolute ceiling on the number of worker threads. The pool only grows past `corePoolSize` toward this number under specific conditions (when the queue is full). - **keepAliveTime** + **unit** — when the pool has more than `corePoolSize` threads, any thread that sits **idle** (no task) for longer than this duration is terminated, shrinking the pool back toward the core size. `unit` is a `TimeUnit` (SECONDS, MILLISECONDS…). This reclaims capacity after a burst of load subsides. - **workQueue** — a `BlockingQueue<Runnable>` that holds tasks submitted while all core threads are busy. A *blocking* queue is one whose operations can wait (block) until space or an element is available; worker threads block on `take()` waiting for the next task. The queue's *type and capacity* hugely affect behavior (bounded vs unbounded vs synchronous — see the queue question). - **threadFactory** — an object whose job is to create each new worker thread. Supplying your own lets you give threads meaningful **names** (priceless in thread dumps/logs), mark them as **daemon** threads (daemons don't keep the JVM alive at shutdown), set **priority**, set a **context class loader**, or install an **UncaughtExceptionHandler**. If you don't pass one, `Executors.defaultThreadFactory()` is used. - **handler** (`RejectedExecutionHandler`) — the policy invoked when a task cannot be accepted, which happens when the queue is full **and** the pool is already at `maximumPoolSize`, or when the pool has been shut down. Built-in policies: `AbortPolicy` (default — throws `RejectedExecutionException`), `CallerRunsPolicy` (the thread that submitted the task runs it itself, which throttles the submitter), `DiscardPolicy` (silently drops the new task), `DiscardOldestPolicy` (drops the oldest queued task and retries). You can also write a custom handler. ## Why each matters - Get **core/max** wrong and you either under-utilize the machine or spawn thousands of threads. - Get the **queue** wrong (e.g. unbounded) and `maximumPoolSize` becomes meaningless and you can run out of heap. - Skip a **ThreadFactory** and every thread is named `pool-1-thread-7`, making production incidents hard to diagnose. - Skip a deliberate **rejection handler** and overload throws exceptions you may not be ready for — or, with a bad choice, silently loses tasks. Understanding all six, and how they interact during task submission, is the foundation of tuning any Java thread pool.