Executors Factory Methods & Risks

## What problem this solves A **thread** is an independent path of execution the operating system schedules. Creating a thread is relatively expensive (memory for its stack, OS bookkeeping), so creating one per task and throwing it away does not scale. A **thread pool** keeps a set of worker threads alive and feeds them a stream of tasks, amortizing the creation cost and bounding how much work runs at once. In Java the abstraction for "submit work, let a pool run it" is **`ExecutorService`** (an interface). You hand it a **`Runnable`** (a task returning nothing) or a **`Callable<T>`** (a task returning a value), and `submit(...)` gives you back a **`Future<T>`** — a handle you can later call `.get()` on to wait for and retrieve the result. ## What `Executors` is `java.util.concurrent.Executors` is a **utility class** (only static methods) of **factory methods** — methods whose job is to construct and return a ready-made object. Each method returns an `ExecutorService` (or the scheduling sub-interface `ScheduledExecutorService`) already configured with a particular strategy, so you don't have to assemble the lower-level `ThreadPoolExecutor` yourself. ## The factory methods - **`newFixedThreadPool(int n)`** — a pool of exactly `n` worker threads. If more tasks arrive than there are free threads, the extras wait in a queue. The queue here is an **unbounded `LinkedBlockingQueue`** (it can hold an effectively unlimited number of waiting tasks). - **`newCachedThreadPool()`** — starts with zero threads and **creates a new thread for every task that arrives when no idle thread is free**. Idle threads are kept for 60 seconds and then discarded. There is no fixed upper limit on thread count (the nominal max is `Integer.MAX_VALUE`). It uses a `SynchronousQueue`, a queue with **zero capacity** — a task can only be handed off if a thread is ready to take it right now, otherwise a new thread is spun up. - **`newSingleThreadExecutor()`** — exactly one worker thread with an unbounded queue. Because there is only one thread, tasks run **one at a time, in submission order** — useful when you need serialization (e.g., writing to a file). It is also wrapped so the thread count can't be reconfigured. - **`newScheduledThreadPool(int n)`** and **`newSingleThreadScheduledExecutor()`** — return a `ScheduledExecutorService`, which adds `schedule(...)` (run once after a delay), `scheduleAtFixedRate(...)`, and `scheduleWithFixedDelay(...)` (run repeatedly). - **`newWorkStealingPool()`** (Java 8) — returns a `ForkJoinPool` sized by default to the number of available processors, where idle threads "steal" queued tasks from busy threads' deques. Good for a large number of small, independent tasks; does **not** guarantee execution order. - **`newVirtualThreadPerTaskExecutor()`** (Java 21) — creates **one virtual thread per task**. A **virtual thread** is a lightweight thread managed by the JVM (not 1:1 with an OS thread), so you can have millions of them cheaply. There is no pooling of platform threads here — every task gets its own virtual thread that simply ends when the task finishes. Ideal for I/O-bound work with very high concurrency. ## How to use one ```java ExecutorService pool = Executors.newFixedThreadPool(4); Future<Integer> f = pool.submit(() -> 2 + 2); int result = f.get(); // 4 pool.shutdown(); // stop accepting tasks; let running ones finish ``` You call `shutdown()` (graceful) or `shutdownNow()` (attempt to cancel) when done, otherwise the non-daemon worker threads keep the JVM alive. ## Why this matters Knowing which factory maps to which behaviour — fixed parallelism, elastic threads, single-threaded ordering, scheduling, work-stealing, or virtual-thread-per-task — lets you pick the right tool. Crucially, the convenient ones (`newFixedThreadPool`, `newCachedThreadPool`) hide *unbounded* resources, which is the central hazard covered by the follow-on questions.