Interrupts and cancellation

For this lesson, we'll build the whole model: why Thread.stop() had to die, what interrupt() actually does to a running, sleeping, parked or I/O-blocked thread, the only two correct ways to handle InterruptedException, and how executors, futures and shutdown hooks are built on top of it. Interviewers love this topic because almost everyone has written catch (InterruptedException e) {} at some point, and the follow-up "what does that break?" separates people who copy patterns from people who understand them.

01Picture it first: a tap on the shoulder, not a trapdoor

Imagine a chef halfway through plating a dish. Thread.stop() was a trapdoor under the chef: they vanish mid-plate, the half-assembled dish goes out to a customer, and the oven they had locked is suddenly unlocked with no one watching it. An interrupt is a tap on the shoulder: "please wrap up". A chef who is waiting (for an oven timer, for an order) reacts at once. A chef in the middle of chopping finishes the cut, checks for taps between cuts, and stops at a clean point.

That tap lands differently depending on what the thread is doing at the moment. This is the single most important picture in the lesson:

Fig. 1

One call to t.interrupt() sets a flag, and the outcome depends on whether t is running, sleeping, parked, doing channel I/O, selecting, or blocked on a monitor

Notice the asymmetry: sleep clears the flag when it throws, while park, channels and selectors leave it set. That one detail explains most interrupt bugs you'll ever debug.

02Why you can't kill a thread: the Thread.stop() story

Java 1.0 shipped Thread.stop(), suspend() and resume(). stop() made the victim throw a ThreadDeath error at whatever bytecode it was executing. As ThreadDeath unwound the stack, every synchronized block exited and every monitor the thread held was released. Picture transfer() holding a lock, having debited account A but not yet credited account B. The lock opens, other threads see money that vanished, and no exception tells them anything is wrong.

suspend() had the opposite problem: the thread froze while still holding its locks. If the thread meant to call resume() needed one of those locks first, the process deadlocked. Here's how the JDK has wound these methods down:

The replacement the Javadoc has recommended since 1.2 is the cooperative pattern: the target thread checks a request regularly and returns from run() in an orderly way, and interrupt() is the way to wake it from long waits. Only the thread itself knows where its consistent stopping points are.

03The interrupt status: one flag, three methods

Every Thread carries one boolean. Three methods touch it:

Here's the everyday version. The interrupt status is a sticky note on someone's monitor saying "please wrap up". isInterrupted() is glancing at the note and leaving it there. Thread.interrupted() is reading it, peeling it off and throwing it in the bin. Whoever looks next sees a clean monitor.

Many candidates mix the last two up because the names are so close. The static one has a side effect: call it twice in a row and the second call returns false. Use it only when you're about to act on the request (throw, or exit), otherwise you have destroyed information someone else needed.

04What responds to an interrupt, and what ignores it

Here's the full inventory I keep in my head. The middle column is what you get; the right column is what to do when a call ignores interrupts.

For the non-responders: replace synchronized with lock.lockInterruptibly() or tryLock(timeout); give sockets a setSoTimeout(...) so reads wake up periodically, or have the cancelling code close the socket, which makes the blocked read() throw SocketException; and make CPU loops poll the flag, which we'll do in a minute.

05Under the hood: interrupting a sleeping worker

Here's the smallest program I use to show all of it. It runs on Java 21:

import java.util.concurrent.locks.LockSupport;

public class InterruptSleeper {

    public static void main(String[] args) throws InterruptedException {
        Thread worker = new Thread(() -> {
            int polls = 0;
            try {
                while (true) {
                    polls++;
                    Thread.sleep(500);              // blocking call: responds to interrupt
                }
            } catch (InterruptedException e) {
                Thread me = Thread.currentThread();
                System.out.println("worker: caught InterruptedException after " + polls + " polls");
                System.out.println("worker: flag inside catch = " + me.isInterrupted());
                me.interrupt();                     // restore the flag for whoever owns this thread
                System.out.println("worker: flag after restore = " + me.isInterrupted());
            }
        }, "worker");

        worker.start();
        Thread.sleep(1_200);
        System.out.println("main: state before interrupt = " + worker.getState());
        worker.interrupt();
        worker.join();
        System.out.println("main: worker is " + worker.getState());

        // Same flag, read two different ways, on the main thread itself
        Thread.currentThread().interrupt();
        System.out.println("isInterrupted() = " + Thread.currentThread().isInterrupted());
        System.out.println("isInterrupted() = " + Thread.currentThread().isInterrupted());
        System.out.println("interrupted()   = " + Thread.interrupted());   // reads AND clears
        System.out.println("interrupted()   = " + Thread.interrupted());

        Thread.currentThread().interrupt();
        long t0 = System.nanoTime();
        LockSupport.park();                         // returns at once: no exception, flag kept
        System.out.printf("park returned in %d us, flag = %b%n",
                (System.nanoTime() - t0) / 1_000, Thread.interrupted());
    }
}

Real output from java InterruptSleeper.java on my laptop:

main: state before interrupt = TIMED_WAITING
worker: caught InterruptedException after 3 polls
worker: flag inside catch = false
worker: flag after restore = true
main: worker is TERMINATED
isInterrupted() = true
isInterrupted() = true
interrupted()   = true
interrupted()   = false
park returned in 57 us, flag = true

Notice four things:

1. The sleeper reacted at once. It was in TIMED_WAITING inside sleep(500); the interrupt cut that sleep short instead of waiting for it to end.
2. The flag was already false inside catch. sleep cleared it on the way out. If this catch block did nothing, the request would be gone for good.
3. isInterrupted() is a pure read; interrupted() is read-and-reset. Same flag, different side effects.
4. park() returned in microseconds with the flag still set. It doesn't throw, so code built on park must check the flag itself. That's exactly what BlockingQueue.take() and friends do internally.

06CPU-bound loops must poll

public class CpuLoops {

    static final long WORK = 3_000_000_000L;   // about 2 s of arithmetic on a laptop

    public static void main(String[] args) throws InterruptedException {
        race("deaf", () -> {                    // never looks at the flag
            long acc = 0;
            for (long i = 0; i < WORK; i++) acc += i ^ (acc >>> 3);
            System.out.println("  deaf: finished all work, acc=" + acc);
        });
        race("polite", () -> {                  // checks the flag every 1,024 iterations
            long acc = 0;
            for (long i = 0; i < WORK; i++) {
                if ((i & 1023) == 0 && Thread.currentThread().isInterrupted()) {
                    System.out.println("  polite: saw the flag at i=" + i + ", acc=" + acc);
                    return;
                }
                acc += i ^ (acc >>> 3);
            }
        });
    }

    static void race(String name, Runnable body) throws InterruptedException {
        Thread t = new Thread(body, name);
        t.start();
        Thread.sleep(100);
        long asked = System.nanoTime();
        t.interrupt();
        t.join();
        System.out.printf("%s: stopped %d ms after interrupt(), flag still set = %b%n",
                name, (System.nanoTime() - asked) / 1_000_000, t.isInterrupted());
    }
}

  deaf: finished all work, acc=1601616558616779095
deaf: stopped 2210 ms after interrupt(), flag still set = true
  polite: saw the flag at i=127713280, acc=2318776813924687298
polite: stopped 1 ms after interrupt(), flag still set = true

The deaf loop ran for another 2.2 seconds and finished all its work as if nothing had happened; the flag sat there, set and unread. The polite loop stopped within about a millisecond. Your numbers will differ by machine, but the shape won't. (isInterrupted() after termination returning true is documented JDK behaviour since JDK 14; the spec itself only promises it "need not have any effect" on a dead thread.)

07Handling InterruptedException: two right answers, one bug

InterruptedException is checked, so the compiler forces you to decide. There are exactly two correct decisions, and the figure shows when to use each.

Fig. 2

When you catch InterruptedException, propagate it if your method can declare it, otherwise restore the flag and exit; swallowing it is the bug

Here's what both look like in code:

// 1. Propagate: the method is blocking, so say so in the signature.
Job nextJob() throws InterruptedException {
    return queue.take();
}

// 2. Restore and exit: run() can't throw checked exceptions.
public void run() {
    try {
        while (!Thread.currentThread().isInterrupted()) {
            process(queue.take());
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();   // keep the request visible to the pool
    } finally {
        releaseResources();
    }
}

Think of a receptionist who takes the call "fire drill, everyone out", says "noted" and hangs up without telling anyone. The building never empties. That's what swallowing an interrupt does to your pool.

The anti-pattern is catch (InterruptedException e) { } or log.warn("interrupted", e); followed by carrying on. Since sleep/take already cleared the flag, swallowing erases the only record of the request. Translating it into an unchecked exception without restoring the flag is the same bug in disguise.