How would you design a long-running worker thread that responds promptly and correctly to cancellation?

## Goal A worker that (a) stops *soon* after being asked, (b) never corrupts shared state, and (c) plays well with thread pools. Java's **interruption** is the standard tool, but using it well means handling *both* the CPU-loop case and the blocking case, plus cleanup. ## The three checkpoints of a cancellable worker ### 1. Poll the flag in compute loops For work that spins on the CPU (no blocking), the thread must *look* at its **interrupt status flag** periodically — the JVM won't break the loop for you: ```java while (!Thread.currentThread().isInterrupted()) { computeChunk(); // keep chunks small enough for prompt response } ``` Use `isInterrupted()` (non-clearing) so the flag persists for cleanup code. ### 2. Catch-and-restore around blocking calls Blocking methods throw `InterruptedException` and **clear the flag**. Catch it, restore the flag, and unwind: ```java try { Object job = queue.take(); // interruptible block handle(job); } catch (InterruptedException e) { Thread.currentThread().interrupt(); // re-set the cleared flag return; // or break the outer loop } ``` ### 3. Clean up in `finally` Whatever causes exit, leave the world consistent: ```java try { ... } finally { lock.unlock(); // release locks closeResources(); // flush/close, roll back partial work } ``` ## How cancellation is triggered - Raw threads: `workerThread.interrupt();` - Executors: `future.cancel(true)` (the `true` = may-interrupt-if-running) interrupts the task's thread; `executorService.shutdownNow()` interrupts all running tasks. These are the idiomatic, higher-level entry points — they all funnel down to `interrupt()`. ## Why not a custom `volatile boolean stop` flag? A plain stop flag works for CPU loops, but it has a fatal gap: it **cannot wake a thread that is blocked** in `sleep()`, `wait()`, or `queue.take()`. That thread won't see your boolean until the block ends — which may be never. Interruption is wired into those blocking methods precisely to break them out. So even if you add a custom flag, you *still* need `interrupt()` for the blocking case — and now you have two mechanisms to keep in sync. Prefer interruption alone; it covers both cases and composes with the whole `java.util.concurrent` ecosystem. (A custom flag is acceptable only as a *supplement* when you need to carry extra cancellation metadata, never as the *replacement* for interruption.) ## Responsiveness vs. throughput How fast you cancel = how often you hit a checkpoint. Long uninterruptible chunks (e.g. a 5-second matrix multiply with no inner check) delay cancellation by that long. Break big computations into chunks and check the flag between them, balancing the per-check overhead against responsiveness. ## Non-interruptible blocking — the gotcha Some blocking is **not** interruptible: classic `synchronized` lock acquisition, blocking I/O on ordinary `InputStream`/`Socket`, and `Lock.lock()`. To stay cancellable, prefer `Lock.lockInterruptibly()`, NIO `InterruptibleChannel`s (which close and throw on interrupt), or close the socket to unblock the reader. A senior answer should mention that interruption is only as prompt as your *most* uninterruptible operation. ## Terms - **Checkpoint:** a point where the thread can notice cancellation (a flag poll or a blocking call). - **Interruptible vs. uninterruptible blocking:** whether a blocking operation reacts to interrupt() or ignores it. - **future.cancel(true):** request to interrupt a running task managed by an executor.