Thread.stop
is being deprecated because it is inherently unsafe. Stopping a thread causes
it to unlock all the monitors that it has locked. (The monitors are unlocked as
the ThreadDeath exception propagates up the stack.) If any of the objects
previously protected by these monitors was in an inconsistent state, other
threads might view these objects in an inconsistent state. Such objects are
said to be damaged .
Threads
operating on damaged objects can behave arbitrarily, either obviously or not.
Unlike other unchecked exceptions, ThreadDeath kills
threads silently; thus, the user has no warning that the program might be
corrupted. The corruption can manifest itself at any time after the actual
damage occurs, even hours or days in the future.
Couldn't I just
catch the ThreadDeath exception and fix the damaged object?
In
theory, perhaps, but it would vastly complicate the task of writing correct
multithreaded code.
The
task would be nearly insurmountable for two reasons:
1. A
thread can throw a ThreadDeath exception almost anywhere. All synchronized
methods and blocks would have to be studied in great detail, with this in mind.
2. A
thread can throw a second ThreadDeath exception while cleaning up from the
first (in the catch or finally clause). Cleanup would have to repeated till it
succeeded. The code to ensure this would be quite complex.
In
sum, it just isn't practical.
So how can we stop
a thread safely? In general:
To
make the thread stop, we organize for the run() method to exit.
No comments:
Post a Comment