How does the executor framework let Command objects be deferred, queued, or scheduled, and which executor supports delayed/periodic execution?

## Why object-ifying the request enables deferral A direct method call (`obj.method()`) runs **immediately, here, now**. The moment you wrap the work in a **Runnable** or **Callable** object, the work becomes a *value* you can store. That single change is what lets a framework **queue** it, **delay** it, **repeat** it, or run it on **another thread** later. This is the practical payoff of the Command pattern. ## Deferred and queued execution: the thread pool A `ThreadPoolExecutor` (created via `Executors.newFixedThreadPool`, etc.) has: - a **pool of worker threads**, and - a **work queue** (a `BlockingQueue`). When you `submit`/`execute` a task and all threads are busy, the task **waits in the queue** until a worker is free. Submission returns immediately; actual execution happens **later**. That gap *is* deferred execution. The queue choice (bounded vs unbounded) and the pool's sizing govern backpressure and how many tasks can pile up. ## Scheduled execution: ScheduledExecutorService For **time-based** running, the JDK provides `ScheduledExecutorService` (created via `Executors.newScheduledThreadPool(n)` or `newSingleThreadScheduledExecutor()`): ```java ScheduledExecutorService ses = Executors.newScheduledThreadPool(2); // 1) Run ONCE after a delay ses.schedule(() -> System.out.println("after 5s"), 5, TimeUnit.SECONDS); // 2) Run repeatedly, period measured from each START ses.scheduleAtFixedRate(task, 0, 1, TimeUnit.SECONDS); // 3) Run repeatedly, gap measured from each task's END ses.scheduleWithFixedDelay(task, 0, 1, TimeUnit.SECONDS); ``` These return a **`ScheduledFuture<V>`** (a Future that also knows its remaining delay) which you can use to cancel the schedule. ### fixedRate vs fixedDelay — the critical distinction - **`scheduleAtFixedRate(task, initialDelay, period, unit)`**: tries to start a new run every `period`, **timed from the previous run's start**. If a run takes *longer* than the period, the next run starts **immediately after** (runs do not overlap on a single-thread scheduler, but can **bunch up** / accumulate lag). - **`scheduleWithFixedDelay(task, initialDelay, delay, unit)`**: waits `delay` **after the previous run finishes** before starting the next. The gap between runs is constant *regardless* of how long each run takes, so runs never pile up. Rule of thumb: use **fixedDelay** when each run's duration varies and you want a steady cool-down; use **fixedRate** when you want runs aligned to a clock cadence and can tolerate catch-up. ### Important gotcha: a thrown task kills the schedule If a periodic task throws an uncaught exception, the scheduler **suppresses further executions** of that task (and the exception is captured in its ScheduledFuture). Always wrap periodic task bodies in try/catch so one failure doesn't silently stop the whole schedule. ## Relation to older APIs `ScheduledExecutorService` supersedes the legacy `java.util.Timer`/`TimerTask`. Timer uses a single thread and a thrown task **kills all** scheduled tasks; the scheduled executor is more robust (pool of threads, per-task isolation of the schedule) and is the recommended choice. ## Key terms - **BlockingQueue**: a thread-safe queue that workers pull tasks from; blocks when empty. - **ScheduledFuture**: a Future returned by scheduling methods; also exposes remaining delay and supports cancellation. - **Period vs delay**: period is start-to-start (fixedRate); delay is end-to-start (fixedDelay). - **Backpressure**: limiting how much queued work accumulates, typically via a bounded queue + rejection policy.