Question

I’ve finally managed to implement Thread.interrupt() into my program instead of Thread.stop(). I am however not sure that I’ve done this well.

I have a class which extends Thread and declares several methods. EVERY method has been made to throw InterruptedException (Each method performs I/O intensive operations, some of which take several minutes to complete, I have therefore not used a thread-safe flag as the flag would not get checked until after the operation completed). I have also added the following code at several places within these methods to throw the exceptions:

if (this.isInterrupted()) throw new InterruptedException();

Within the run() method I execute all methods within a try/catch for InterruptedException. If caught, I execute Process.destroy() and BufferedReader.close() for my class variables.

This all works, and seems to work very well, however I have a couple of questions:

1. Is it correct to have more than 10 methods, all of which throw InterruptedException? Is there a better way to do this?
2. Is it correct to bloat the methods with checks for isInterrupted()?
3. At the end of the catch InterruptedException block, must I execute a ‘return’, or ‘null’ certain values to make the Thread available for GC? If I re-create the Thread it takes longer than usual to initialize.
4. Finally, are there any issues/enhancements related to what I’ve done?

Thanks in advance for your help!

Answer 1

Thread interruption in Java doesn’t mean stopping the execution of that thread. It is not stop, it is interrupt. A thread can be interrupted when something fundamental and crucial changes, telling the thread that its execution context, its task or its enviroment changed in some significant way. A thread reaction to this message is implementation specific. It can be stop, it can be restart or any other action. A thread that doesn’t handle interruptions cannot be interrupted, but its behaviour can still be altered, for example, by using a shared variable.

For example, imagine you have a number of threads, all searching through a part of a problem space for a solution. When one thread finds a solution, it can interrupt other threads, because their search for a solution is no longer relevant. A solution has already been found.

Or imagine one continuously working main thread and one network communication thread. Each time the network thread receives a messsage, it interrupts the working thread with the message. Based on what the message and the context is, the worker thread may decide what to do next. For example, if the message was “STOP”, then it could stop all execution immediately. If the message was “RESET”, it could start again from scratch or maybe not from scratch and reuse some previous work, based on the execution context.

Is it correct to have more than 10 methods, all of which throw
InterruptedException? Is there a better way to do this?

No, this is perfectly fine, as long as you know what you are doing. If you implement interruptions to just stop the threads, there is no need to throw InterruptedExceptions. A Thread’s run() method is it’s first, and the exception will not go any further the stack.

Is it correct to bloat the methods with checks for isInterrupted()?

Depending on the context. The checks would be usually added before some crucial code. Usually it is added as a first item in the loop block.

At the end of the catch InterruptedException block, must I execute a
‘return’, or ‘null’ certain values to make the Thread available for
GC? If I re-create the Thread it takes longer than usual to
initialize.

No. Once the Thread exists from the run() method, it’s left at GC’s mercy. Shared variables will not be GC’ed, as long as they are still referenced by other objects.