Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →In Java, interrupting a thread is a cooperative cancellation request—not a command that kills it. Thread.interrupt() sets the thread’s interrupted status or causes certain interruptible blocking operations to return early; the thread’s code must respond by stopping, cleaning up, or handing the request onward.
What does thread interruption mean in Java?
Oracle describes an interrupt as “an indication to a thread that it should stop what it is doing and do something else.” (Oracle Java Tutorials) The target thread decides how to respond. Code that never checks its status or enters an interruptible operation can continue running.
This makes interruption a standard mechanism for communicating cancellation or a change of task. It is not equivalent to forcibly terminating a thread: Java does not arbitrarily stop the thread’s code when another thread calls interrupt().
What happens when you call Thread.interrupt()?
The result depends on what the target thread is doing. During ordinary execution, interrupt() sets its interrupted status. If the target is in certain interruptible blocking operations, the operation instead responds according to its own contract. Oracle’s Java SE 26 Thread API documents the key cases:
Free tools Windows power users keep installed
One-click scans. No signup required.
Object.wait(),Thread.sleep(), andThread.join()throwInterruptedExceptionwhen interrupted. The status is cleared before the exception is thrown.- A thread blocked on an
InterruptibleChannelhas the channel closed and receivesClosedByInterruptException; its interrupted status remains set. - A thread blocked in a
Selectorreturns early with interrupted status set, similarly to a selector wakeup. Condition.await()is interruptible: it throwsInterruptedExceptionand clears the status.
These differences matter: do not assume every blocking call throws InterruptedException, or that every kind of interruption clears the flag.
How do interrupted() and isInterrupted() differ?
Both expose interrupted status, but they check different threads and have different effects:
| Method | Which thread? | Clears status? | Typical use |
|---|---|---|---|
Thread.interrupted() |
The current thread | Yes | Check and consume the current thread’s interrupt request when that is intentional. |
thread.isInterrupted() |
The specified thread | No | Check status without consuming it, including when polling from a loop. |
After Thread.interrupted() returns true, a second immediate call returns false unless another interrupt arrives, because the first call cleared the status. Use isInterrupted() when code should observe cancellation without clearing the signal.
Rank #2
Why does catching InterruptedException clear the flag?
For operations such as sleep, wait, join, and Condition.await(), clearing status is part of the documented exception behavior. The exception tells the blocked operation that interruption occurred; the cleared flag means a handler cannot assume the status is still set afterward.
The handler should preserve the cancellation signal for its caller or surrounding executor. Oracle’s current API guidance is: “Code that catches InterruptedException should rethrow the exception, or restore the current thread’s interrupted status.” (Oracle Java SE 26 Thread API)
How should a Java worker respond to interruption?
Choose a response based on whether the worker is blocked or doing CPU-bound work, whether its method can declare the checked exception, who owns cleanup, and whether it is performing NIO channel or selector I/O.
Blocking worker: propagate when possible
If the method can declare InterruptedException, do minimal necessary cleanup and rethrow it. This allows a caller to decide whether to cancel, exit, or propagate the request further.
void runTask() throws InterruptedException {
while (hasMoreWork()) {
performBlockingStep(); // may throw InterruptedException
}
}Do not catch the exception just to log it and continue: the blocking operation has cleared the status, so doing nothing loses the cancellation request.
Method cannot declare it: restore status
When a method’s signature cannot include InterruptedException, restore the current thread’s status before returning or translating the failure. For example:
Rank #4
void runWorker() {
try {
waitForWork();
} catch (InterruptedException e) {
cleanUp();
Thread.currentThread().interrupt();
return;
}
}The cleanup should be limited to work the handler is responsible for; after restoring the flag, return or otherwise stop the current operation rather than continuing as if cancellation never happened.
Translating the exception: keep both signals
If application code must throw a different exception, restore the status and retain the original exception as the cause:
try {
waitForWork();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new WorkerFailedException("Worker interrupted", e);
}The caller receives the application-level failure, while the thread’s interrupt status and exception cause preserve the cancellation information.
Best Value
CPU-bound loop: poll at safe boundaries
A computation that does not call an interruptible operation must check status itself. Poll periodically at points where the work can safely stop:
while (hasMoreWork()) {
if (Thread.currentThread().isInterrupted()) {
cleanUp();
return;
}
processNextItem();
}Polling frequency is a design choice: checking too rarely delays response, while checking at a safe unit of work makes cleanup and partial results easier to manage. Since isInterrupted() does not clear the flag, the cancellation request remains visible.
Common interruption mistakes
- Treating interrupt as thread termination: it only signals the target; code must cooperate.
- Swallowing
InterruptedException: catching, logging, and continuing loses the signal after the blocking method clears status. - Using
Thread.interrupted()as a passive check: it clears status. PreferisInterrupted()when the check should not consume the signal. - Assuming all I/O responds identically: channels and selectors have distinct behavior from methods that throw
InterruptedException. - Continuing after restoring status: restoration preserves the request; the code still needs to return, propagate, or otherwise stop at an appropriate boundary.
The Thread.sleep(Duration) overload is documented as available since Java 19 in the Java SE 26 API; its interruption behavior follows the sleep contract.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors
