|
|
|
|
Back to newsletter 176 contents
A tiny change in Java 8 is that Thread.stop(Throwable) is now
disabled - it now throws an UnsupportedOperationException
instead of working as it did in earlier Java versions. Thread.stop()
still works (ie the stop() call with no argument).
It's likely you've never used either of these calls (apart
from maybe just testing when playing around to understand
threads), and it's true that both have been deprecated for
many many years now (since 1998). It is normally recommended
that you shouldn't have any type of Thread.stop() call in your
code, because if you do, you're probably doing something wrong.
I'll leave it to you to read up on the reason why they're unsafe
(which is why they've been deprecated for years). The choice to
disable one of the two in Java 8 was a bit idiosyncratic - mainly
because it's been deprecated for so long that it was felt that
it was time to finally disable it. Thread.stop(Throwable) was
chosen as it was the less used and more dangerous of the two
(because it lets you throw an arbitrary throwable on any thread).
There is one seemingly valid use-case for keeping the remaining
Thread.stop() working - as a last ditch attempt for killing
rogue threads in correctly implemented code (threads which you
can identify as not correctly operating, you need them to die
for whatever reason but you'd rather not terminate the process).
But if you've tried this then you've seen threads which haven't
responded to Thread.stop() in correctly implemented interruptable
code because they're stuck in some kind of native section; and
others in loops that wouldn't die (sometime loops can be killed,
sometimes not). Generally, this means that there is no reliable
way to kill a rogue thread. There're two strategies for dealing
with this: 1. Treat the thread as a zombie, just leave it doing
effectively nothing and start another thread that works; or
2. Spawn a separate process that IS killable to do the work.
This latter approach is relatively common and Java is being
gradually enhanced to allow better control over spawned
processes, for example Java 8 now has a Process.destroyForcibly()
method for rogue spawned processes; and of course you can use
something like
ChronicleMap (was SharedHashMap) or
MappedBus
or any (preferably simple) IPC mechanism to coordinate across
the processes. It seems a little clunky to do it this way, but
spawning child processes and killing them if necessary is a tried
and tested way of maintaining full control over resource usage.
Now on to all our usual sections: links to tools, articles,
news, talks and as ever, all the
extracted tips from all of this
month's referenced articles.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 176 contents
