Walk through the built-in RejectedExecutionHandlers (AbortPolicy, CallerRunsPolicy, DiscardPolicy, DiscardOldestPolicy). What does each do and when would you choose each?

## The rejection hook When a `ThreadPoolExecutor` cannot run a task immediately (no idle thread) and cannot queue it (queue full or refusing) and cannot grow (already at `maximumPoolSize`) — or when the executor has been shut down — it calls: ``` handler.rejectedExecution(Runnable task, ThreadPoolExecutor executor) ``` `RejectedExecutionHandler` is a single-method interface. The JDK ships four implementations as static nested classes of `ThreadPoolExecutor`. ### AbortPolicy (the default) Throws a `RejectedExecutionException` — an unchecked `RuntimeException`. The exception propagates out of `execute()`/`submit()` to the caller. - **Pros:** fail-fast and loud; you never silently lose work, and the caller can react (retry, alert, shed). - **Cons:** the caller must handle the exception; an unhandled one can crash a request thread. - **Use when:** correctness matters and dropped work is unacceptable; you want overload to be visible. ### CallerRunsPolicy Does **not** throw and does **not** drop. Instead it runs the task's `run()` **directly on the calling (submitting) thread** — provided the executor isn't shut down. The clever effect: while the submitter is busy executing the rejected task, it **cannot submit new tasks**, so the production rate is throttled to match consumption. This is a built-in **backpressure / flow-control** mechanism. - **Pros:** no task loss, automatic throttling, no extra threads. - **Cons:** the submitting thread (possibly an event loop, HTTP acceptor, or another pool's thread) is blocked running the work, which can stall latency-sensitive paths or, in pathological setups, deadlock if that thread is itself needed to drain the pool. - **Use when:** you want graceful degradation under load and the caller can afford to do the work. ### DiscardPolicy **Silently drops** the rejected task. No exception, no logging, the task simply never runs (its `Future`, if any, never completes normally). - **Pros:** trivially sheds load. - **Cons:** silent data loss — extremely easy to mask a real problem; futures hang forever. - **Use when:** the work is genuinely best-effort and losing it has no consequence (e.g. dropping a redundant cache-warm task). ### DiscardOldestPolicy If the executor isn't shut down, it **polls (removes) the head of the work queue** — the oldest, longest-waiting task — discards it, and then **retries** `execute(task)` for the new one. It prefers newer work over stale. - **Pros:** keeps the freshest tasks; useful when newer data supersedes older (e.g. latest sensor reading). - **Cons:** silently drops a task that was first in line (possibly the most important / most-aged), and with a `PriorityBlockingQueue` the 'head' is the *highest-priority* element, so it would discard your most important task — usually wrong there. - **Use when:** newest-wins semantics and FIFO staleness is the real enemy. ## Custom handlers Because `RejectedExecutionHandler` is a one-method interface, you can supply your own to: log + meter rejections, push to a dead-letter queue or persistent store for later retry, apply a bounded blocking put (`queue.put`) to throttle without busy-running the caller, or trigger autoscaling. A common production pattern is a logging+metrics handler so overload is observable rather than silent. ## Choosing - **Fail fast / never lose work:** AbortPolicy (or a custom handler that retries/persists). - **Throttle producers, no loss:** CallerRunsPolicy. - **Shed load, loss acceptable:** DiscardPolicy (any age) or DiscardOldestPolicy (drop stale). Always pair an unbounded queue's *absence* (i.e. use a bounded queue) with a deliberate handler — the handler only ever runs when the queue can actually fill.