InterruptedException and interrupting threads explained

Tomasz NurkiewiczJune 2nd, 2014Last Updated: June 3rd, 2014

0 171 4 minutes read

If InterruptedException wasn’t checked exception, probably no one would even notice it – which would actually prevent couple of bugs throughout these years. But since it has to be handled, many handle it incorrectly or thoughtlessly. Let’s take a simple example of a thread that periodically does some clean up, but in between sleeps most of the time.

class Cleaner implements Runnable {

  Cleaner() {
    final Thread cleanerThread = new Thread(this, "Cleaner");
    cleanerThread.start();
  }

  @Override
  public void run() {
    while(true) {
      cleanUp();
      try {
        TimeUnit.SECONDS.sleep(1);
      } catch (InterruptedException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
      }
    }
  }

  private void cleanUp() {
    //...
  }

}

This code is wrong on so many layers!

Starting Thread in a constructor might not be a good idea in some environments, e.g. some frameworks like Spring will create dynamic subclass to support method interception. We will end-up with two threads running from two instances.
InterruptedException is swallowed, and the exception itself is not logged properly
This class starts a new thread for every instance, it should use ScheduledThreadPoolExecutor instead, shared among many instances (more robust and memory-effective)
Also with ScheduledThreadPoolExecutor we could avoid coding sleeping/working loop by ourselves, and also switch to fixed-rate as opposed to fixed-delay behaviour presented here.
Last but not least there is no way to get rid of this thread, even when Cleaner instance is no longer referenced by anything else.

All problems are valid, but swallowing InterruptedException is its biggest sin. Before we understand why, let us think for a while what does this exception mean and how we can take advantage of it to interrupt threads gracefully. Many blocking operations in JDK declare throwing InterruptedException, including:

Object.wait()
Thread.sleep()
Process.waitFor()
AsynchronousChannelGroup.awaitTermination()
Various blocking methods in java.util.concurrent.*, e.g. ExecutorService.awaitTermination(), Future.get(), BlockingQueue.take(), Semaphore.acquire() Condition.await() and many, many others
SwingUtilities.invokeAndWait()

Notice that blocking I/O does not throw InterruptedException (which is a shame). If all these classes declare InterruptedException, you might be wondering when is this exception ever thrown?

When a thread is blocked on some method declaring InterruptedException and you call Thread.interrupt() on such thread, most likely blocked method will immediately throw InterruptedException.
If you submitted a task to a thread pool (ExecutorService.submit()) and you call Future.cancel(true) while the task was being executed. In that case the thread pool will try to interrupt thread running such task for you, effectively interrupting your task.

Knowing what InterruptedException actually means, we are well equipped to handle it properly. If someone tries to interrupt our thread and we discovered it by catching InterruptedException, the most reasonable thing to do is letting said thread to finish, e.g.:

class Cleaner implements Runnable, AutoCloseable {

  private final Thread cleanerThread;

  Cleaner() {
    cleanerThread = new Thread(this, "Cleaner");
    cleanerThread.start();
  }

  @Override
  public void run() {
    try {
      while (true) {
        cleanUp();
        TimeUnit.SECONDS.sleep(1);
      }
    } catch (InterruptedException ignored) {
      log.debug("Interrupted, closing");
    }
  }

  //...   

  @Override
  public void close() {
    cleanerThread.interrupt();
  }
}

Notice that try-catch block now surrounds while loop. This way if sleep() throws InterruptedException, we will break out of the loop. You might argue that we should log InterruptedException‘s stack-trace. This depends on the situation, as in this case interrupting a thread is something we really expect, not a failure. But it’s up to you. The bottom-line is that if sleep() is interrupted by another thread, we quickly escape from run() altogether. If you are very careful you might ask what happens if we interrupt thread while it’s in cleanUp() method rather than sleeping? Often you’ll come across manual flag like this:

private volatile boolean stop = false;

@Override
public void run() {
  while (!stop) {
    cleanUp();
    TimeUnit.SECONDS.sleep(1);
  }
}

@Override
public void close() {
  stop = true;
}

However notice that stop flag (it has to be volatile!) won’t interrupt blocking operations, we have to wait until sleep() finishes. On the other side one might argue that explicit flag gives us better control since we can monitor its value at any time. It turns out thread interruption works the same way. If someone interrupted thread while it was doing non-blocking computation (e.g. inside cleanUp()) such computations aren’t interrupted immediately. However thread is marked as interrupted and every subsequent blocking operation (e.g. sleep()) will simply throw InterruptedException immediately – so we won’t loose that signal.

We can also take advantage of that fact if we write non-blocking thread that still wants to take advantage of thread interruption facility. Instead of relying on InterruptedException we simply have to check for Thread.isInterrupted() periodically:

public void run() {
  while (Thread.currentThread().isInterrupted()) {
    someHeavyComputations();
  }
}

Above, if someone interrupts our thread, we will abandon computation as soon as someHeavyComputations() returns. If it runs for two long or infinitely, we will never discover interruption flag. Interestingly interrupted flag is not a one-time pad. We can call Thread.interrupted() instead of isInterrupted(), which will reset interrupted flag and we can continue. Occasionally you might want to ignore interrupted flag and continue running. In that case interrupted() might come in handy. BTW I (imprecisely) call “getters” that change the state of object being observed “Heisengetters“.

Note on `Thread.stop()`

If you are old-school programmer, you may recall Thread.stop() method, which has been deprecated for 10 years now. In Java 8 there were plans to “de-implement it”, but in 1.8u5 it’s still there. Nevertheless, don’t use it and refactor any code using Thread.stop() into Thread.interrupt().

`Uninterruptibles` from Guava

Rarely you might want to ignore InterruptedException altogether. In that case have a look at Uninterruptibles from Guava. It has plenty of utility methods like sleepUninterruptibly() or awaitUninterruptibly(CountDownLatch). Just be careful with them. I know they don’t declare InterruptedException (which might be handful), but they also completely prevent current thread from being interrupted – which is quite unusual.

Summary

By now I hope you have some understanding why certain methods throw InterruptedException. The main takeaways are:

Caught InterruptedException should be handled properly – most of the time it means breaking out of the current task/loop/thread entirely
Swallowing InterruptedException is rarely a good idea
If thread was interrupted while it wasn’t in a blocking call, use isInterrupted(). Also entering blocking method when thread was already interrupted should immediately throw InterruptedException.

Reference:

InterruptedException and interrupting threads explained from our JCG partner Tomasz Nurkiewicz at the Java and neighbourhood blog.