Java threading introduction  Thread-safety  Thread methods  Interruption  Thread scheduling  Context switching  Thread priorities  sleep()  yield()  Deadlock  Threading with Swing  invokeLater()  Thread pools  CoundDownLatch  ThreadPoolExecutor  CyclicBarrier

Threads Database Profiling Regular expressions Random numbers Compression Exceptions C Equivalents in Java

Thread interruption in Java (ctd)

On the previous page, we looked at the basics of thread interruption in Java. On this page, we'll explore a few more details that we need to consider.

What if the interruptee isn't doing a blocking call?

In the above example, you may be thinking, "what if the call to interrupt() happens while the other thread is printing the message (rather than in the Thread.sleep() call)?". Well, it turns out not to matter in this case. If the interruptee is not in a blocking method, then:

  • interrupt() will set an interrupted flag on the interruptee;
  • the next time the thread makes a blocking call such as Thread.sleep(), that call will immediately throw the InterruptedException.

So provided that the interrupted thread periodically calls a blocking call such as Thread.sleep(), the interruption mechanism still works.

What if the interrupted method isn't ever (or soon) going to call a blocking method like like sleep() or wait()? In this case:

  • interrupt() will not automatically interrupt the thread if it does not make any blocking calls;
  • but we can manually check for the interrupted flag and implement cancellation ourselves.

To manually check for the interrupted flag, we call isInterrupted(). For example:

public void performLongCalculation() throws InterruptedException {
  for (int i = 0; i < PART_COUNT; i++) {
    if (isInterrupted())
      throw new InterruptedException();

This technique is usually more useful when the thread is performing a combination of interruptible and non-interruptible calls. Otherwise, we can implement our own cancellation flag (typically via a volatile boolean).

How to handle InterruptedException?

A common piece of bad program design is to "micro-manage" InterruptedException (and indeed, exceptions in general), by catching it and "pretending nothing happened". But in a good design, like any exception, it should be dealt with cleanly. What exactly to do with InterruptedException can depend on the program and situation, of course, but as a rule of thumb:

An InterruptedException should cause the overall task to be cancelled.

This generally means:

  • inside the run() method of a thread (or the Runnable run by a thread), InterruptedException should generally cause the run() method to terminate (as in the example above)— here, it arguably doesn't matter whether you also, say, log it or take some other action;
  • inside the run() method of a Runnable passed to another JDK utility class (such as an Executor), it's generally best to set the thread's interrupted status again, so that the consuming class can detect the interruption and take appropriate action (JDK classes that consume Runnables generally will do this):
    public class MyRunnable implements Runnable() {
      BlockingQueue pendingStrings;
      public void run() {
        try {
          while (true) {
            String str = pendingStrings.take();
        } catch (InterruptedException iex) {
    This is necessary because catching InterruptedException clears the thread's interrupted status, so the caller would otherwise have no way of knowing that the interruption occurred.
  • in a utility method that makes a blocking call, it's usually best to let the method throw the InterruptedException back up to the caller.

 Java threading articles  Java threading and concurrency  Java profiling  Java performance graph index

Unless otherwise stated, the Java programming articles and tutorials on this site are written by Neil Coffey. Suggestions are always welcome if you wish to suggest topics for Java tutorials or programming articles, or if you simply have a programming question that you would like to see answered on this site. Most topics will be considered. But in particular, the site aims to provide tutorials and information on topics that aren't well covered elsewhere, or on Java performance information that is poorly described or understood. Suggestions may be made via the Javamex blog (see the site's front page for details).
Copyright © Javamex UK 2016. All rights reserved.