Why can a pool from Executors.newFixedThreadPool lead to OutOfMemoryError under load even though the number of threads is fixed?

## Background: what a fixed pool really is `Executors.newFixedThreadPool(n)` is a one-line convenience over the real engine, **`ThreadPoolExecutor`**. A `ThreadPoolExecutor` has four key knobs: - **corePoolSize** — threads kept alive even when idle. - **maximumPoolSize** — the hard cap on threads. - **workQueue** — a `BlockingQueue<Runnable>` where tasks wait when all core threads are busy. - **RejectedExecutionHandler** — what happens when a task can't be accepted. The fixed-pool factory sets `corePoolSize == maximumPoolSize == n` and supplies `new LinkedBlockingQueue<Runnable>()`. ## The hidden detail: the queue is unbounded A **`BlockingQueue`** is a queue that can block a producer when full or a consumer when empty. A **`LinkedBlockingQueue`** created **without a capacity argument** defaults to a capacity of `Integer.MAX_VALUE` — for all practical purposes, **unbounded**. So while the *thread* count is fixed at `n`, the number of *waiting tasks* is not bounded by anything except heap memory. ## How a ThreadPoolExecutor decides where a task goes When you `submit` a task, the executor: 1. If fewer than `corePoolSize` threads exist, start a new thread for it. 2. Else, try to **enqueue** it. 3. Only if the queue is *full* does it try to grow toward `maximumPoolSize`. 4. If it can't grow and can't enqueue, it **rejects** the task via the handler. Because the fixed pool's queue is never full, step 2 always succeeds. Steps 3 and 4 are unreachable. So every task that the `n` threads can't immediately run just sits in the queue. ## Why that becomes an OutOfMemoryError Suppose producers submit 1,000 tasks/sec but the `n` threads can only complete 600/sec. The backlog grows by 400 tasks every second. Each queued task is a live object on the **heap** (the managed memory region), and it retains everything it references (the closure/captured variables, request payloads, etc.). The backlog grows linearly forever, heap fills, and eventually the JVM cannot allocate and throws **`OutOfMemoryError: Java heap space`**. Threads were never the problem — the *queue* was. ## The second, subtler problem: no back-pressure **Back-pressure** means a slow consumer can signal a fast producer to slow down. With an unbounded queue, `submit()` always returns instantly and never blocks or fails, so the producer gets **no feedback** that the system is falling behind. The application looks healthy (low rejection, low latency on submit) right up until it dies. By the time the OOM hits, you may have lost in-flight work and have no graceful degradation. ## The remedy Build the pool explicitly with a **bounded** queue and an explicit rejection policy: ```java ThreadPoolExecutor pool = new ThreadPoolExecutor( 8, 8, // core == max 60L, TimeUnit.SECONDS, new ArrayBlockingQueue<>(1000), // BOUNDED queue new ThreadPoolExecutor.CallerRunsPolicy()); // back-pressure on overload ``` Now when 1,000 tasks are already waiting, the next `submit` triggers the `RejectedExecutionHandler`. `CallerRunsPolicy` runs the task on the submitting thread, which naturally slows the producer (true back-pressure); `AbortPolicy` (the default) throws `RejectedExecutionException` so overload fails fast and visibly. Either way the system degrades predictably instead of silently exhausting memory. This is the core reason experts often **avoid the `Executors` fixed/single factories in favour of configuring `ThreadPoolExecutor` directly**.