What does it mean to interrupt a thread in Java, and what does calling interrupt() actually do?
answer
- interrupt() just sets a boolean flag
- not a kill switch — cooperative
- poll the flag OR catch InterruptedException
- Thread.stop() was deprecated for safety
- thread that never checks ignores it
basics
~10 sCalling interrupt() on a thread just sets a boolean flag on it asking it to stop. It does not forcibly kill the thread. The thread must check the flag and decide to stop itself.
solid answer
~40 sInterruption in Java is a cooperative cancellation mechanism, not a kill switch. Calling t.interrupt() sets that thread's internal interrupt-status flag to true. It does not stop the thread, throw anything across threads, or abandon work. The interrupted thread is responsible for noticing the request and winding down gracefully. There are two ways it notices: a long-running loop polls Thread.currentThread().isInterrupted() and returns when it sees true; or, if the thread is blocked in a method like sleep(), wait(), or join(), that method throws InterruptedException immediately. So the contract is: the interrupter politely asks, and the worker cooperates by checking the flag or catching the exception. Threads that ignore interruption simply keep running, which is why writing interruptible code is the programmer's responsibility, not the JVM's.
code
java · 11 lines// Cooperative cancellation: the worker polls the flag.
Thread worker = new Thread(() -> {
while (!Thread.currentThread().isInterrupted()) {
// do a chunk of CPU work...
}
System.out.println("Noticed interrupt, stopping cleanly.");
});
worker.start();
// From another thread: politely ask it to stop.
worker.interrupt(); // just sets the flag; worker exits its loop next checkgo deeper
Knows interrupt() sets a flag and is a request, not a forced stop; can describe the two ways a thread notices (polling and InterruptedException).
Explains why the cooperative model exists (Thread.stop() was unsafe), and can write a loop that polls isInterrupted() to exit cleanly.
Articulates the full contract, knows which methods clear the flag vs leave it set, and designs cancellable tasks that combine polling with exception handling.
Frames interruption as the standard cancellation protocol across java.util.concurrent (Future.cancel, ExecutorService.shutdownNow) and sets team conventions for propagating cancellation through layers and libraries.
## The problem interruption solves Sometimes you want to stop a running thread early: a user cancels a download, a request times out, or an app is shutting down. Java's old `Thread.stop()` method did this forcibly, but it was deprecated decades ago because killing a thread mid-operation can leave shared data in a broken, half-updated state (locks released with invariants violated). Java replaced it with a **cooperative** model called **interruption**: you *ask* a thread to stop, and well-written threads *cooperate* by stopping themselves at a safe point. ## What `interrupt()` actually does Every `Thread` object carries a hidden boolean called the **interrupt status flag** (also "interrupt status"), initially `false`. Calling `someThread.interrupt()` from any thread sets that flag to `true`. **That is all it does in the common case** — it does not pause, kill, or throw anything into the running code. The interrupted thread keeps executing normally until *it* chooses to look at the flag. ```text Thread A: workerThread.interrupt(); // sets workerThread's flag = true, returns instantly Thread B (the worker): ... keeps running until it checks the flag ... ``` ## How a thread "notices" it was interrupted There are exactly two mechanisms: 1. **Polling.** Code that loops doing CPU work checks the flag itself, e.g. `while (!Thread.currentThread().isInterrupted()) { ... }`. When the flag flips to `true`, the loop exits and the thread returns from its task. 2. **Blocking methods throw.** If the thread is *blocked* inside `Thread.sleep(...)`, `Object.wait(...)`, `Thread.join(...)`, or many `java.util.concurrent` operations (e.g. `BlockingQueue.take()`), and the flag is (or becomes) set, that method **clears the flag** and throws a checked `InterruptedException`. This wakes the thread up immediately instead of making it wait for the timeout. So a responsive thread combines both: it polls the flag in its CPU loops and catches `InterruptedException` around its blocking calls. ## Why "cooperative" Because the JVM never forcibly stops the thread, a thread that never checks its flag and never blocks will simply ignore the interrupt forever. Interruption is therefore a *convention*: the platform provides the flag and the exception, but **your code must honor it**. This is a deliberate trade for safety — the thread stops only at points it controls, so it can release resources and leave shared state consistent. ## Key terms - **Interrupt status flag:** a per-thread boolean meaning "someone asked me to stop." - **Cooperative cancellation:** stopping by request + voluntary checking, not by force. - **InterruptedException:** the checked exception blocking methods throw to signal a pending interrupt.
- If interrupt() only sets a flag, how does a thread blocked in sleep() stop almost instantly?Blocking methods like sleep()/wait()/join() are wired to monitor the interrupt status; when it is set they abandon the wait, clear the flag, and throw InterruptedException, so the thread wakes immediately rather than waiting out the full duration.
- Can you interrupt a thread that is stuck in a tight CPU loop with no blocking calls and no flag checks?You can call interrupt() and the flag will be set, but the loop will never notice it because it neither blocks nor polls isInterrupted(), so it runs to completion regardless. The loop must be written to poll the flag.
saying these in an interview costs you the question
- Thinking interrupt() forcibly stops or kills the thread
- Believing interrupt() throws an exception in the target thread from the outside
- Assuming an interrupted thread stops automatically without checking the flag
- Confusing interruption with Thread.stop()/suspend()