Java Thread.interrupted clears the current thread's signal

Last updated: 30 Sept 20264 min read

tutorial

Thread.interrupted reads and clears the current thread's interrupt status; isInterrupted reads it without clearing it.

One call consumes the signal

The fixture interrupts its own thread, reads the flag without clearing it, then calls Thread.interrupted. A final isInterrupted call is false. There is no timing race or worker thread in this program.

Code that catches InterruptedException after a blocking call commonly needs to stop or restore the flag with Thread.currentThread().interrupt(). Polling Thread.interrupted in a helper can accidentally consume a cancellation signal intended for a higher layer. Cancellation covers task ownership.

Interruption is cooperation

An interrupt does not forcibly roll back database work or undo partial output. Define an operation boundary at which a worker can stop, and test resource cleanup separately. Executor ownership determines who can request cancellation.

Working program

public class InterruptionReadBoundary {
    public static void main(String[] args) {
        Thread worker = Thread.currentThread();
        worker.interrupt();
        System.out.println("before=" + worker.isInterrupted());
        System.out.println("consumed=" + Thread.interrupted());
        System.out.println("after=" + worker.isInterrupted());
    }
}

Output

before=true
consumed=true
after=false

Costs and boundaries

These status reads are constant-time control operations. The fixture verifies flag semantics only; it does not prove cancellation latency, cleanup, or thread-pool behavior.

Common Mistakes

Do not call Thread.interrupted merely to inspect without clearing.
Do not swallow InterruptedException and continue as though no cancellation was requested.
Do not equate interruption with transaction rollback.