How Does Thread.interrupt() Work, and Why Never Swallow InterruptedException?

“How does Thread.interrupt() actually work, and why must you never swallow InterruptedException?”

interrupt() is a request, not a command — calling it just sets a boolean flag on the target thread; nothing stops on its own. A thread currently blocked in a method that supports interruption (Thread.sleep, Object.wait, Thread.join, BlockingQueue.take/put) notices the flag, clears it, and throws InterruptedException. A thread doing plain CPU-bound work notices nothing automatically — the running code has to poll isInterrupted() itself for cancellation to have any effect.

interrupt()

sets a flag, doesn't stop anything

Blocking methods

detect flag → clear it → throw InterruptedException

CPU-bound code

must poll isInterrupted() itself

Swallowing it

catch (InterruptedException e) {} discards the cancellation signal entirely

// WRONG — silently discards the interrupt signal
try {
    Thread.sleep(1000);
} catch (InterruptedException e) {
    // swallowed — the thread has no idea it was asked to stop
}

// RIGHT — restore the flag (or propagate) so callers up the stack know
try {
    Thread.sleep(1000);
} catch (InterruptedException e) {
    Thread.currentThread().interrupt(); // restore status
    return; // actually stop what you were doing
}

Key takeaway: restoring the flag with Thread.currentThread().interrupt() — rather than just returning — matters because the blocking method already cleared it. If this code is called from something further up the stack that also checks isInterrupted() (a thread-pool worker loop, for example), that caller still needs to see the interrupt request. Restoring the flag hands the signal upward instead of losing it.

Two similarly-named methods read the flag very differently — mixing them up is a common source of bugs. thread.isInterrupted() (instance method) just reads the flag and leaves it alone; call it twice and you get the same answer both times. Thread.interrupted() (static method, always acts on the currently running thread) reads the flag and clears it as a side effect — call it twice in a row and the second call returns false even if nothing else changed. The static form exists so a loop can check-and-reset in one step; using it on the assumption it behaves like the instance method is a classic way to silently lose an interrupt request.

Every graceful-shutdown or timeout path in Java — ExecutorService.shutdownNow(), a request timeout, a user cancelling a long operation — ultimately relies on the running task cooperating with interruption. A task that swallows InterruptedException, or never checks isInterrupted() in a long loop, simply cannot be cancelled no matter how correctly the caller requests it.

Keywords they're listening for:

• ✓ interrupt() sets a flag, never force-stops a thread
• ✓ blocking methods clear the flag and throw InterruptedException
• ✓ CPU-bound code must poll isInterrupted() for cancellation to work
• ✓ never swallow InterruptedException — restore the flag or propagate it

• ✗catch (InterruptedException e) {} with an empty body
• ✗Assuming interrupt() forcibly stops whatever the thread is doing
• ✗Not checking isInterrupted() in long CPU-bound loops, making them effectively uncancellable
• ✗Catching InterruptedException and continuing the loop instead of stopping

• ✓Either propagate InterruptedException up (declare it) or restore the flag with Thread.currentThread().interrupt() before handling it locally
• ✓Poll isInterrupted() periodically in long CPU-bound loops
• ✓Treat interruption as Java's standard cancellation mechanism, not an edge case to work around

1. 1What's the difference between the instance method isInterrupted() and the static Thread.interrupted()?
2. 2Why does the static Thread.interrupted() clear the flag when you call it?
3. 3How does ExecutorService.shutdownNow() use interruption under the hood?
4. 4Can you interrupt a thread that's doing pure CPU work with no blocking calls?

• InterruptedException
• Thread.interrupt
• ExecutorService.shutdownNow
• cooperative cancellation