Question

I am actually looking for an easier way to kill the thread not matter where the thread is running at. But most of the solutions in internet point me to use boolean flag to control the execution of the thread, if I want to stop the thread then set the boolean variable to false.

But what if the task that in the runnable is a LONG linear task, which mean the task is not repeating? In that case, it is not so easy to create a ‘while’ loop to cover the whole block of task.

It is really so temptative to use Thread.stop but the warning “Deprecated” seem like quite dangerous to use. I have read through this article
Why Are Thread.stop, Thread.suspend, Thread.resume and Runtime.runFinalizersOnExit Deprecated?

but I can’t understand

If any of the objects previously protected by these monitors were in
an inconsistent state, other threads may now view these objects in an
inconsistent state. Such objects are said to be damaged.

What does the “inconsistent state” mean? I appreciate if anyone can explain about this.

I want to extend my question to a more lower level of view, let say i = i + 1; in JVM (perhaps assembly language alike), maybe this Java statement will be split into few smaller instructions, for example like move i ; add i ; get i into memory 0x0101 (This is an example! I totally don’t know assembly language!)

Now, if we call thread.stop, where actually will it stop at? Will the thread stop after a COMPLETED Java statement, or could be in the middle of the “assemble language”? If the answer is the second, could it be reason that we said

Such objects are said to be damaged.

?

Ok, my question is kind of confused, hope someone can understand and explain. Thanks in advance.

Answer 1

The “inconsistent state” means state of data as your application cares about, state that your application logic have carefully produced by making your application thread-safe with locks/monitors etc.

Imagine you have this simple method:

public synchronized void doSomething() 
{
      count++;
      average = count/total;
}

This method, along with other methods are synchronized, as multiple threads are using this object.
Perhaps there’s a

public synchronized AverageAndCount getMeasurement() 
{
   return new AverageAndCount(average, count);
}

This assures that a thread can’t read an incomplete measurement, i.e. if the current measurement is in the process of being calculated inside e.g. doSomething(), getMeasurement() will block/wait until that’s finished.

Now, imagine the doSomething is run in a thread, and you call .stop() on that thread.

So the thread might be stopped right after it performs count++;, the monitor that’s held is unlocked and the method terminates and average = count/total; is not executed,

That means the data is now inconsistent. Anyone calling getMeasurement() afterwards will now get inconsistent data.

Note also that at this point it is not very relevant whether this happens at a java statement level, or at a lower level, the data can be in an inconsistent state that you can’t reason about in any case.