Time to put a stop to Thread.stop?
dawid.weiss at gmail.com
Wed May 15 07:00:14 UTC 2013
To contribute to the discussion concerning Thread.stop(*) and its
usefulness. I've implemented a JUnit test runner for Lucene/ Solr and
we needed test suite isolation badly but at the same time wanted to
reuse the same JVM (for performance reasons).
The initial implementation worked by detecting "leaked" threads (those
started within a test suite and crossing its lifecycle boundary) and
then tried to gracefully interrupt them; if this didn't help, an
attempt to "kill" those threads was issued with a call to
This works very well on small examples only. In practice what happens is:
1) you get loops with a catch (Throwable) inside; pretty much prevents
the thread from being stopped (these we called ChuckNorris-type...),
2) threads going into native sections and hung there (not necessarily
via JNI, even via system IO calls),
Eventually we just dropped thread.stop altogether -- if a thread
cannot be interrupted, it is considered a "zombie" and the test
framework either proceeds or aborts entirely (depending on the
So, based on this experience my point of view on the matter is that
Thread.stop() is useless. For rethrowing checked exceptions you can
use the generics-based sneaky throw. If you have control over the code
of the threads you want to stop then you shouldn't use Thread.stop()
anyway. For any code you don't have the control over it's not 100%
reliable so I doubt its use is really fully justified.
A much more needed addition to the standard library in place of
Thread.stop() would be methods to acquire:
1) your own PID (this one is in planning for 1.8 or even has been
2) forked process PID (?),
3) a way to kill the forked process (and possibly its sub-tree).
These are platform-specific operations and the "workarounds" for these
missing API calls are truly horrible, even if implemented nicely (see
sources of Jenkins for example ).
More information about the core-libs-dev