Consider the following code from java.util.concurrent.locks.AbstractQueuedSynchronizer as one of the many examples of the idea presented in the title:
1258 public final boolean tryAcquireSharedNanos(int arg, long nanosTimeout) throws Interrupted Exception {
1259 if (Thread.interrupted())
1260 throw new InterruptedException();
1261 return tryAcquireShared(arg) >= 0 ||
1262 doAcquireSharedNanos(arg, nanosTimeout);
1263 }
Why do most blocking library methods respond to interruption by calling the static method Thread.interrupted() instead of instance method isInterrupted() . Calling the static method also clears the interrupted status so if even the task handling code swallows the InterruptionException , there is no way for the callers to get to know about the interrupted status other than
It is always true that if you catch an
InterruptedException, the interrupted flag has already been cleared. The exception itself is your signaling mechanism at that point. The catcher is required to either re-enable the flag or take care directly that the thread moves to a close.