What does Executors.newScheduledThreadPool provide, and why is it generally preferred over java.util.Timer?

## What scheduling means here Sometimes you don't want a task to run *now* but **after a delay** (run in 5 seconds) or **periodically** (run every minute). Java's `ScheduledExecutorService` interface extends `ExecutorService` with three methods for this, and `Executors.newScheduledThreadPool(n)` is the factory that gives you an implementation backed by `n` worker threads. ## The three scheduling methods - **`schedule(task, delay, unit)`** — run the task **once**, after `delay` time units. Returns a `ScheduledFuture` (a `Future` you can cancel or query). - **`scheduleAtFixedRate(task, initialDelay, period, unit)`** — run repeatedly; each execution is scheduled to **start `period` after the previous execution's *start*time**. If a run takes longer than `period`, subsequent runs don't overlap (the executor won't run two at once for the same task) but they queue up and fire back-to-back to "catch up". - **`scheduleWithFixedDelay(task, initialDelay, delay, unit)`** — run repeatedly; each execution starts `delay` after the previous one **finishes**. This guarantees a fixed *gap* between runs regardless of how long each takes — usually the safer choice for jobs of variable duration. The difference between the two repeating modes matters: *fixed rate* tries to keep a steady cadence (good for sampling at exact intervals); *fixed delay* keeps a steady idle gap (good for polling where you don't want overlap or pile-up). ## The old way: java.util.Timer `java.util.Timer` (with `TimerTask`) is the pre-`java.util.concurrent` scheduling tool. It has several well-known defects that `ScheduledThreadPoolExecutor` fixes: 1. **Single thread.** A `Timer` uses exactly one background thread. If one task runs long, **every other scheduled task is delayed** behind it. A scheduled pool with `n > 1` runs tasks concurrently, so a slow task doesn't starve the rest. 2. **No failure isolation.** If a `TimerTask` throws an **unchecked exception** (a `RuntimeException`/`Error`), it **kills the Timer's thread**, and *all* remaining scheduled tasks are silently cancelled — the whole Timer is dead. With `ScheduledThreadPoolExecutor`, an exception is confined to that one execution; the pool and other tasks keep going. (Note: for a *repeating* scheduled task, an uncaught exception suppresses *future runs of that same task*, so you should still catch inside the task — but it does not take down the pool or other tasks.) 3. **Absolute-time sensitivity.** `Timer` schedules against the **system wall-clock**, so if the OS clock is changed (NTP adjustment, manual change, DST), timings can misfire. `ScheduledThreadPoolExecutor` schedules on **relative delays from a monotonic source**, so it is immune to wall-clock jumps. ## Why this is the recommended tool Because of multi-threading, per-task failure isolation, monotonic timing, and the richer `ScheduledFuture` return (cancel, check done/delay), the consensus (including *Effective Java*) is: **use `ScheduledThreadPoolExecutor` / `Executors.newScheduledThreadPool`, not `Timer`.** ## The hazard it still shares It is built on a `ThreadPoolExecutor` whose work queue (a `DelayedWorkQueue`) is **unbounded**, so the same backlog-OOM caution from the other factories applies if you schedule far more tasks than `n` threads can drain. Size `n` for the expected concurrency, keep periodic tasks short, and always catch exceptions inside repeating tasks so a single failure doesn't silently stop future runs. ## Example ```java ScheduledExecutorService s = Executors.newScheduledThreadPool(2); s.scheduleWithFixedDelay( () -> { try { poll(); } catch (Exception e) { log.warn("poll failed", e); } }, 0, 30, TimeUnit.SECONDS); // run, then 30s gap, repeat ``` Wrapping the body in try/catch keeps a transient failure from cancelling all future runs of this periodic task.