ExecutorService extends Executor with a lifecycle. Walk through shutting one down correctly, contrasting shutdown(), shutdownNow(), and awaitTermination().

## Why a lifecycle exists The base `Executor` interface can only *run* tasks — it has no notion of stopping. But a real **thread pool** owns long-lived **worker threads**. Those threads must eventually be released, both to free resources and because **non-daemon** threads (the default for pool threads) keep the JVM from exiting. So the `ExecutorService` subinterface adds **lifecycle** methods. An ExecutorService is in one of three logical states: **running** (accepting and executing tasks), **shutting down** (no new tasks accepted, draining existing ones), and **terminated** (all tasks done, threads released). ## shutdown() — graceful, orderly ```java void shutdown(); ``` - **Stops accepting new tasks.** Any later `submit`/`execute` is rejected with `RejectedExecutionException`. - **Lets already-submitted tasks finish** — both currently running tasks and tasks still waiting in the queue run to completion. - **Does not block.** It returns immediately; the draining happens in the background. ## shutdownNow() — best-effort immediate stop ```java List<Runnable> shutdownNow(); ``` - **Stops accepting new tasks** (same as shutdown). - **Attempts to stop running tasks** by calling `Thread.interrupt()` on each worker. This is *cooperative*: a task only actually stops if it checks `Thread.currentThread().isInterrupted()` or calls a blocking method that throws `InterruptedException` (like `sleep`, `wait`, `take`). A tight CPU loop that ignores interruption will **not** stop. - **Drains the queue** and **returns** the `List<Runnable>` of tasks that were waiting but never started — so the caller can handle or re-submit them. ## awaitTermination() — wait for completion ```java boolean awaitTermination(long timeout, TimeUnit unit) throws InterruptedException; ``` - **Blocks** the calling thread until either (a) all tasks have completed and the service is terminated, or (b) the timeout elapses, whichever comes first. - Returns **true** if it terminated within the timeout, **false** if the timeout expired first (tasks still running). - Crucially, awaitTermination does **not** itself initiate shutdown — you must call `shutdown()` or `shutdownNow()` first; otherwise it will just wait out the full timeout and return false. ## The recommended two-phase idiom The JDK docs prescribe this graceful-then-forceful pattern: ```java void shutdownAndAwait(ExecutorService pool) { pool.shutdown(); // phase 1: stop new work, drain try { if (!pool.awaitTermination(30, TimeUnit.SECONDS)) { pool.shutdownNow(); // phase 2: interrupt stragglers if (!pool.awaitTermination(10, TimeUnit.SECONDS)) { // log: pool did not terminate } } } catch (InterruptedException e) { pool.shutdownNow(); // re-shutdown if WE were interrupted Thread.currentThread().interrupt();// restore interrupt status } } ``` The logic: ask nicely (`shutdown`), give running work a grace period (`awaitTermination`), and if it overstays, interrupt it (`shutdownNow`) and wait briefly again. If our own waiting thread gets interrupted, we force shutdown and restore the interrupt flag (so callers up the stack still see it). ## Inspecting state - `isShutdown()` — true once shutdown/shutdownNow has been called (may still be draining). - `isTerminated()` — true only once all tasks have actually finished after a shutdown. ## Java 19+: AutoCloseable Since Java 19, `ExecutorService` implements `AutoCloseable`. Its `close()` does essentially the graceful idiom: `shutdown()`, then await termination (retrying with interrupts). So you can write: ```java try (ExecutorService es = Executors.newFixedThreadPool(4)) { es.submit(task); } // close() blocks until tasks finish — no leaked threads ``` ## The classic bug: forgetting to shut down If you never shut down a pool whose threads are non-daemon, those threads stay alive and **the JVM will not exit** even after `main` returns. In long-running servers this is a thread leak: every un-shut-down pool keeps its worker threads forever. Always pair pool creation with a shutdown (try-with-resources, a `finally`, or a lifecycle hook).