Methods that Clear the Thread.interrupt() flag

Question

I have recently inherited a large Java Application that has almost no Thread safety in it. What I'm currently working on is getting all of the Threads to correctly handle being interrupted instead of using the very bad Thread.stop().

Part of the problem has been that I do not know every method call out there that clears the interrupt flag.

Currently I know that the following will clear the interrupt flag:

Thread.interrupted()
Thread.sleep(long)
Thread.join()
Thread.join(long)
Object.wait()
Object.wait(long)

What else am I missing? Thank you

Answer 1

Part of the problem has been that I do not know every method call out there that clears the interrupt flag.

It is important to clarify that the following methods clear the interrupt flag by just calling them:

Thread.interrupted()
Thread.isInterrupted(true) -- added to your list

For this reason Thread.currentThread().isInterrupted() should always be used instead.

The following methods will clear the interrupted flag by immediately throwing InterruptedException either if they were called and then the thread was interrupted or if the thread was already interrupted and then they were called (see junit code below). So it is not the method that clears the flag, throwing the exception does.

Thread.sleep(long)
Thread.sleep(long, int) – added to your list
Thread.join()
Thread.join(long)
Thread.join(int, long) – added to your list
Object.wait()
Object.wait(long)
Object.wait(int, long) – added to your list
BlockingQueue.put(...) – added to your list
BlockingQueue.offer(...) – added to your list
BlockingQueue.take(...) – added to your list
BlockingQueue.poll(...) – added to your list
Future.get(...) – added to your list
Process.waitFor() – added to your list
ExecutorService.invokeAll(...) – added to your list
ExecutorService.invokeAny(...) – added to your list
ExecutorService.awaitTermination(...) – added to your list
CompletionService.poll(...) – added to your list
CompletionService.take(...) – added to your list
CountDownLatch.await(...) – added to your list
CyclicBarrier.await(...) – added to your list
Semaphore.acquire(...) – added to your list
Semaphore.tryAcquire(...) – added to your list
Lock.lockInteruptibly() – added to your list
Lock.tryLock(...) – added to your list

Please note that the proper pattern with any code that catches InterruptedException is to immediately re-interrupt the thread. We do this in case others are relying on the thread.isInterrupted() method:

try {
    ...
} catch (InterruptedException e) {
    // immediately re-interrupt the thread
    Thread.currentThread().interrupt();
    // log the exception or [likely] quit the thread
}

JUnit code that demonstrates some of this:

assertFalse(Thread.currentThread().isInterrupted());
// you can do this from another thread by saying: someThread.interrupt();
Thread.currentThread().interrupt();
// this method does _not_ clear the interrupt flag
assertTrue(Thread.currentThread().isInterrupted());
// but this one _does_ and should probably not be used
assertTrue(Thread.interrupted());
assertFalse(Thread.currentThread().isInterrupted());
Thread.currentThread().interrupt();
assertTrue(Thread.currentThread().isInterrupted());
try {
    // this throws immediately because the thread is _already_ interrupted
    Thread.sleep(1);
    fail("will never get here");
} catch (InterruptedException e) {
    // and when the InterruptedException is throw, it clears the interrupt
    assertFalse(Thread.currentThread().isInterrupted());
    // we should re-interrupt the thread so other code can use interrupt status
    Thread.currentThread().interrupt();
}
assertTrue(Thread.currentThread().isInterrupted());

Answer 2

Common convention is the following: any method that throws InterruptedException (+ Thread.interrupted()) clears the interrupt flag.

So, in order to make your threads interruptable you need to find all places where InterruptedException gets caught without retrowing it or restoring the interrupt flag. Since InterruptedException is a checked exception it's not hard to do.

Answer 3

Here's a SUPER FUN EXAMPLE:

ch.qos.logback.core.AsyncAppenderBase prior to version 1.1.4 catches and swallows InterruptedException without resetting the flag on the thread.

So, if you use anything which routes to this logger (like slf4j), it will silently eat your thread interrupt status. 'Cos, I mean, who doesn't check thread interrupt status before and after every possible log operation?