What is the difference between the instance method isInterrupted() and the static method Thread.interrupted()?
answer
- isInterrupted = instance, does NOT clear
- Thread.interrupted = static, DOES clear (current thread)
- static one always means the current thread
- loop guard → use isInterrupted
- clearing variant = consume/acknowledge the interrupt
basics
~10 sBoth read the interrupt flag. isInterrupted() (instance) just reads it and leaves it unchanged. The static Thread.interrupted() reads it for the current thread AND clears it back to false.
solid answer
~50 sThere are two ways to query the interrupt status, and the crucial difference is whether they clear the flag. thread.isInterrupted() is an instance method: it returns the interrupt status of that thread object and does not change it — you can call it repeatedly and keep getting true. Thread.interrupted() is a static method that operates on the current thread only; it returns the status and then resets it to false as a side effect. So it's a read-and-clear (test-and-reset). The practical rule: use isInterrupted() when you just want to check, e.g. in a loop condition, because it's non-destructive. Use the static interrupted() only when you deliberately want to consume and clear the flag, such as at the top of a task that needs to start with a clean status. A classic bug is calling Thread.interrupted() inside a loop condition expecting it to keep returning true — it clears the flag, so the second check returns false and your cancellation logic silently breaks.
code
java · 8 linesThread.currentThread().interrupt(); // set the flag
boolean a = Thread.currentThread().isInterrupted(); // true (no clear)
boolean b = Thread.currentThread().isInterrupted(); // true (still set)
Thread.currentThread().interrupt(); // set again
boolean c = Thread.interrupted(); // true -> and CLEARS
boolean d = Thread.interrupted(); // false (was cleared by c)go deeper
Knows isInterrupted() reads the flag; may not yet recall that the static interrupted() also clears it.
Clearly states the clear-vs-not difference, that the static method targets the current thread, and picks isInterrupted() for loop guards.
Explains why a clearing variant exists, diagnoses the loop-condition trap, and knows when consuming the flag is the right design.
Sets conventions so library/framework code never accidentally clears interrupts it doesn't own, preserving cancellation signals across abstraction boundaries.
## Two methods, one flag Recall that every thread has a single **interrupt status flag** — a boolean meaning "a stop was requested." Java exposes two methods to read it, and they look almost identical but behave differently in one decisive way: **whether they clear the flag**. ### `isInterrupted()` — instance, non-clearing ```java boolean b = someThread.isInterrupted(); ``` - It's an **instance** method: you call it on a specific `Thread` object (often `Thread.currentThread()`). - It **returns** the flag's value and **leaves it unchanged**. - Idempotent: call it ten times in a row and you get `true` ten times (until something else clears it). - Used for *checking* — ideal in loop guards: `while (!Thread.currentThread().isInterrupted())`. ### `Thread.interrupted()` — static, clearing ```java boolean b = Thread.interrupted(); ``` - It's a **static** method that *always* refers to the **currently executing thread** — it ignores any thread object even if you (misleadingly) write `someThread.interrupted()`. - It **returns** the flag's value and then **resets it to `false`** as a side effect. This is a **test-and-clear** (a.k.a. read-and-reset). - Call it twice in a row when the flag was set: the first returns `true` and clears; the second returns `false`. ## Why a clearing variant exists Sometimes you want to *consume* the interrupt — acknowledge "yes, I saw the request" and start fresh. For example, a thread-pool worker finishing one task and about to pick up another may clear the status so a stale interrupt doesn't leak into the next task. The clear-on-read semantics give you that in one call. ## The classic trap ```java // BUG: clears the flag on the first iteration while (!Thread.interrupted()) { // static -> reads and CLEARS doWork(); } ``` If the flag is set, the first evaluation returns `true` (so `!true` is `false`) and the loop *does* exit — but it has now **cleared** the flag, so any outer code that also wanted to see the interrupt won't. Worse, if you mistakenly expect `Thread.interrupted()` to keep reporting `true`, you'll be surprised. The safe idiom is the non-clearing instance form: ```java while (!Thread.currentThread().isInterrupted()) { doWork(); } ``` ## Quick decision rule - **Just checking, want it to persist?** → `Thread.currentThread().isInterrupted()`. - **Deliberately want to read and clear the current thread's flag?** → `Thread.interrupted()`. ## Terms - **Test-and-clear / read-and-reset:** an operation that returns the current value *and* sets it back to a default in the same step. - **Idempotent read:** a read that you can repeat without changing the result.
- Why does calling someOtherThread.interrupted() not check that other thread?interrupted() is static; the compiler resolves it to Thread.interrupted(), which always operates on Thread.currentThread(). Calling it through an instance reference is misleading syntax — it ignores the receiver and checks/clears the caller's own flag.
- When would you intentionally use the clearing behavior of Thread.interrupted()?When you want to consume the interrupt — e.g. a pool worker resetting status between tasks so a leftover interrupt from a prior task doesn't falsely cancel the next one, or after you've fully handled the cancellation locally and don't want it observed again.
saying these in an interview costs you the question
- Thinking both methods clear the flag (only the static one does)
- Using Thread.interrupted() in a loop condition expecting repeated true
- Believing someThread.interrupted() checks someThread (it always checks the current thread)
- Not realizing the static method has a side effect at all