Thread.Stop() - Deprecated

Thread.stop() - deprecated

You asked:

My question is if theres no way to stop a thread in Java then how to stop a thread?

The Answer: In Java there's no clean, quick or reliable way to stop a thread.

Thread termination is not so straight forward. A running thread, often called by many writers as a light-weight process, has its own stack and is the master of its own destiny (well daemons are). It may own files and sockets. It may hold locks. Abrupt Termination is not always easy: Unpredictable consequences may arise if the thread is in the middle of writing to a file and is killed before it can finish writing. Or what about the monitor locks held by the thread when it is shot in the head?

Instead, Threads rely on a cooperative mechanism called Interruption. This means that Threads could only signal other threads to stop, not force them to stop.

To stop threads in Java, we rely on a co-operative mechanism called Interruption. The concept is very simple. To stop a thread, all we can do is deliver it a signal, aka interrupt it, requesting that the thread stops itself at the next available opportunity. That’s all. There is no telling what the receiver thread might do with the signal: it may not even bother to check the signal; or even worse ignore it.

Source: https://codeahoy.com/java/How-To-Stop-Threads-Safely/

Non-cooperative Thread.stop() alternative in modern Android

There is no "modern" alternative. The old alternatives are still the only ones. Why? Because this is fundamentally an unsolvable problem¹ ... if the threads are not cooperating or if are able to correctly unpick things when they field an interrupt.

For the record, the technical reasons that Thread.stop() is unsafe include:

It breaks mutual exclusion locks help by the thread being stopped. This may leave the object that was locked ... or other objects ... in an inconsistent state.
It may result in broken inter-thread signalling. For example, if a thread is expected to notify a condition variable, and it gets stopped before this happen, then other threads may be stuck forever waiting for a notify that never arrives.

If has said that issues such as the above can in theory be addressed by application code on a case-by-base basis by catching ThreadDeath and taking remedial action. But to borrow someone else's words, "it would be insanely messy".

I'm sorry if you think this is all unsatisfactory. But this is life. If you cannot write your threads to be cooperative, and you need them to be killable, run them in an external process, via Process etcetera.

Now ... if we could wave a magic wand and replace Java threads with a CSP-like model of concurrency (and eschew state sharing between processes), then the problem goes away. Though now you have to deal with the other problem of what to do with the messages queued up when a process is terminated. But at least that is a tractable problem.

^{1 - I am asserting this without proof! However, if it was a solvable problem, then you would have thought that Sun or Oracle or Google would have discovered and implemented a solution in the last ... umm ... 25 years. Challenge: If you can come up with a viable implementation model for safely killing Java threads, I expect that certain companies would be willing to offer you a very well-paid job. Especially if they can secure exclusive rights on your patent.}

Alternate to Thread.stop() in Java 8?

If you really need to stop a Thread the hard way you may consider that the method Thread.stop() (without providing an arbitrary Throwable) still works with Java 8. It will generate a ThreadDeath on the stopped thread which can be handled like any other Error, despite its unusual name. The only difference is that no stack trace will be printed if ThreadDeath is not caught.

But beware that this method is deprecated for most of the same reasons than the other stop method. It might become unspported in one of the next releases of Java. So it’s still time to think about a plan B…

Why thread.stop deprecated and timer.cancel is not?

Cancelling a timer doesn't have any of the potentially destabilizing behaviour of aborting a thread. From the docs:

Does not interfere with a currently executing task (if it exists).

In other words, it's not going to try to stop a task which is already running, which could potentially end up with monitors not being released etc. It's just going to avoid running any more tasks.

Thread.Stop() - Deprecated