About Tomasz Nurkiewicz

Java EE developer, Scala enthusiast. Enjoying data analysis and visualization. Strongly believes in the power of testing and automation.

InterruptedException and interrupting threads explained

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!

  1. 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.
  2. InterruptedException is swallowed, and the exception itself is not logged properly
  3. This class starts a new thread for every instance, it should use ScheduledThreadPoolExecutor instead, shared among many instances (more robust and memory-effective)
  4. 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.
  5. 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 observedHeisengetters“.

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.
Related Whitepaper:

Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code

Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!

To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.

Get it Now!  

Leave a Reply


+ 5 = six



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books