Net thread stop

Question

Finally, I managed to implement Thread.interrupt () in my program instead of Thread.stop (). However, I am not sure that I did it well.

I have a class that extends Thread and declares several methods. EACH was done in order to throw an InterruptedException (each method performs intensive I / O operations, some of which take several minutes, so I did not use the flag flag, because the flag did not get checked before the operation was completed). I also added the following code in several places in these methods to eliminate exceptions:

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

In the run () method, I execute all the methods in try / catch for an InterruptedException. If it is caught, I execute Process.destroy () and BufferedReader.close () for my class variables.

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

• Is it right to have more than 10 methods, all of which raise InterruptedException? Is there a better way to do this?
• Is it right to inflate methods with checks on isInterrupted ()?
• At the end of the catch block of InterruptedException, should I execute "return" or "null" specific values ​​to make Thread available to the GC? If I recreate Thread, it will take longer to initialize than usual.
• Finally, are there any problems / improvements related to what I did?

Thanks in advance for your help!

Answer 1

Interrupting a thread in Java does not mean stopping the execution of this thread. This is not a stop, this is an interrupt. A thread can be interrupted when some fundamental and important change occurs, telling the thread that its execution context, its task, or its environment has changed in some significant way. The flow response to this message is implementation specific. It can be a stop, it can be a restart or any other action. A thread that does not handle interrupts cannot be interrupted, but its behavior can be changed, for example, using a shared variable.

For example, imagine that you have several threads, all of them are viewing part of the problem space for a solution. When one thread finds a solution, it can interrupt other threads because their search for a solution no longer matters. A solution has already been found.

Or imagine one continuous workflow and one network communication flow. Each time a network stream receives a messsage, it interrupts the workflow with the message. Based on what the message and context are, a workflow can decide what to do next. For example, if the message was "STOP", it could immediately stop all execution. If the message was "RESET", it can start again from scratch or maybe not from scratch and reuse previous work based on the execution context.

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

No, that’s fine if you know what you’re doing. If you are doing interrupts to just stop threads, there is no need to throw InterruptedExceptions. The Thread run () method is the first, and the exception will not go further than the stack.

Is it right to inflate methods with checks on isInterrupted ()?

Depending on the context. Checks were usually added before some important code. Usually it is added as the first element in the loop block.

At the end of the catch block of InterruptedException, do you need to execute 'return' or 'null' specific values ​​to make Thread available to the GC? If I recreate Thread, it will take longer than usual initialization.

No. Once Thread exists from the run () method, it remains at the mercy of the GC. Shared variables will not be GC'ed if they are still referenced by other objects.