Java Stop task
For almost a year now I have been intensively engaged in coding in Java. Faced a rather serious problem in my opinion related to multithreading, it seems to me, unsolvable in the framework of the current implementation of JVM from Oracle (the above applies to JDK 1.5 and higher). The fact is that at the moment in Java there is no way to guaranteedly stop the execution of any thread. This post explains why this is the case and suggests starting a discussion on how to solve this problem.
It would seem a trivial task: we have a certain Thread(stream), which, we know for sure, hangs hopelessly (maybe it got stuck, maybe something else), while consuming some resources. What shall we do with it? I would like to free our resources. It would seem that easier? But no, upon a detailed study of the issue, it turned out that the JVM simply does not have an instruction to correctly stop the hanging Thread. The old Thread.stop () method is declared Deprecated and anathematized. As stated in javadoc, this method is "essentially unsafe." Well, if we’re not safe, we won’t use it, give us another, safe method. But another safe, oddly enough, is not offered. Of course, a very safe Thread.interrupt () statement is suggested.. But she is safe, unfortunately, because she absolutely does nothing! This is just a message to the stream: "Please stop." But if the thread ignored this message then ... as stated in the documentation "If the thread does not respond to Thread.interrupt (), you can use tricks specific to your application." Thank you for allowing. What’s called, spin as you want.
Everything becomes even more complicated if the task is launched in the thread pool, through, for example, ExecutorService.submit (Runnable) . At the same time, we don’t even know in which thread the given task is being executed and can no longer even use the forbidden Thread.stop (). On the other hand, we have a link to Future , and Future has a Future.cancel (boolean) methodwhich should cancel the task. But if the task has already started, calling Future.cancel (true) will not actually stop it. In the bowels of the FutureTask implementation, the code is executed: i.e. again, the thread in which the task is running is only advised to stop execution. In addition, we do not even have the opportunity to find out whether the task is currently being performed or not. There is, like, the Future.isDone () method , but again by, it returns true not only when the task completed execution, but immediately after calling Future.cancel (), even if the task is still running (because Future.cancel (true) is not stops a task that has already started to run). Well, if we write all the code ourselves, then you can carefully process it in the right places
Thread.isInterrupted () and everything will be OK. But if we run third-party code? Should we have an extensible server with plugins? Some crookedly written plugin can easily lead to an inoperable state of the entire server, because we cannot correctly interrupt the execution of a frozen plugin.
I admit, I do not know a satisfactory solution. Maybe the Thread.stop () method is not so dangerous? I'd love to hear the opinions of Java programmers practitioners about this.
It would seem a trivial task: we have a certain Thread(stream), which, we know for sure, hangs hopelessly (maybe it got stuck, maybe something else), while consuming some resources. What shall we do with it? I would like to free our resources. It would seem that easier? But no, upon a detailed study of the issue, it turned out that the JVM simply does not have an instruction to correctly stop the hanging Thread. The old Thread.stop () method is declared Deprecated and anathematized. As stated in javadoc, this method is "essentially unsafe." Well, if we’re not safe, we won’t use it, give us another, safe method. But another safe, oddly enough, is not offered. Of course, a very safe Thread.interrupt () statement is suggested.. But she is safe, unfortunately, because she absolutely does nothing! This is just a message to the stream: "Please stop." But if the thread ignored this message then ... as stated in the documentation "If the thread does not respond to Thread.interrupt (), you can use tricks specific to your application." Thank you for allowing. What’s called, spin as you want.
Everything becomes even more complicated if the task is launched in the thread pool, through, for example, ExecutorService.submit (Runnable) . At the same time, we don’t even know in which thread the given task is being executed and can no longer even use the forbidden Thread.stop (). On the other hand, we have a link to Future , and Future has a Future.cancel (boolean) methodwhich should cancel the task. But if the task has already started, calling Future.cancel (true) will not actually stop it. In the bowels of the FutureTask implementation, the code is executed: i.e. again, the thread in which the task is running is only advised to stop execution. In addition, we do not even have the opportunity to find out whether the task is currently being performed or not. There is, like, the Future.isDone () method , but again by, it returns true not only when the task completed execution, but immediately after calling Future.cancel (), even if the task is still running (because Future.cancel (true) is not stops a task that has already started to run). Well, if we write all the code ourselves, then you can carefully process it in the right places
if (mayInterruptIfRunning) {
Thread r = runner;
if (r != null)
r.interrupt(); }
Thread.isInterrupted () and everything will be OK. But if we run third-party code? Should we have an extensible server with plugins? Some crookedly written plugin can easily lead to an inoperable state of the entire server, because we cannot correctly interrupt the execution of a frozen plugin.
I admit, I do not know a satisfactory solution. Maybe the Thread.stop () method is not so dangerous? I'd love to hear the opinions of Java programmers practitioners about this.