...
| Wiki Markup |
|---|
Invoking {{Thread.stop()}} results in the release of all the locks a thread has acquired, which maycould corrupt the state of the object. The thread could catch the {{ThreadDeath}} exception and use a {{finally}} block in an attempt to repair the inconsistent object. However, this requires careful inspection of all the synchronized methods and blocks because a {{ThreadDeath}} exception can be thrown at any point during the thread's execution. Furthermore, code must be protected from {{ThreadDeath}} exceptions that maycould result when executing {{catch}} or {{finally}} blocks \[[Sun 1999|AA. Bibliography#Sun 99]\]. |
...
Because the Vector class is thread-safe, operations performed by multiple threads on its shared instance are expected to leave it in a consistent state. For instance, the Vector.size() method always returns the correct number of elements in the vector, even in the face of concurrent changes to the vector. This is because the vector instance uses its own intrinsic lock to prevent other threads from accessing it while its state is temporarily inconsistent.
...
Removing the default permission java.lang.RuntimePermission stopThread permission from the security policy file prevents threads from being stopped using the Thread.stop() method. This approach is not recommended for trusted, custom-developed code that uses that method because the existing design presumably depends upon the ability of the system to perform this action. Furthermore, the system may might not be designed to properly handle the resulting exception. In these cases, it is preferable to implement an alternate design approach corresponding to another compliant solution described in this guideline.
...
Forcing a thread to stop can result in inconsistent object state. Critical resources may could also leak if clean-up operations are not carried out as required.
...