Reliably stopping an unresponsive thread
denial-of-service, java, multithreading
Solution
It may not be possible, at least not reliably in every scenario.
IF I understand the mechanism correctly (and there is some uncertainty there), if the code executes in such a way that there are no safepoints during the execution (for example in counted loops), it is not possible for the JVM to signal to the thread that it should stop (the thread never polls for an interrupt).
In such a scenario, you need to kill the JVM process, rather than the thread.
Some extra reading:
How to get Java stacks when JVM can't reach a safepoint
Counted loops
Problem
I'm wondering how to stop an unresponsive thread in Java, such that it's really dead. First of all, I'm well aware of `Thread.stop()` being deprecated and why it should not be used; there are already many excellent answers on this topic, cf. [1][2]. So, the question more precisely is, whether it's actually technically possibly to kill a thread which code is not controlled by us but possibly hostile and not responding to interrupts. In the simplest case, a hostile thread would be running `while(true);`, but it could as well be using up memory or other system resources to do more damage. Calling `interrupt()` on that thread is obviously ineffective. What about calling `stop()` instead? I have run this in a debugger and, in fact, the thread really disappears. But is this approach reliable? The hostile thread could be prepared for this case; think of `try{run();}catch(ThreadDeath t){run();}` where it catches the `ThreadDeath` that is produced when we call `stop()` and recursively calls itself again. As an outside observer, we cannot see what is going on; `Thread.stop()` always runs silently. Worst of all, the usual diagnostics won't work anymore (tried this while debugging on Corretto 1.8.0_275 Windows x64): `Thread.getState()` always returns `RUNNABLE` regardless of success in killing the thread, same goes for `Thread.isAlive()` (always true).